RFC: types conflicts

[Peter Mamonov]

Hello, Ahmad,

On Mon, Apr 19, 2021 at 09:58:06AM +0200, Ahmad Fatoum wrote:
> Hello Peter,
> 
> On 7/8/20 11:02 PM, Peter Mamonov wrote:
> >>> I tried to build MicroPython using barebox toolchain and found a number of
> >>> conflicts between barebox and compiler headers. Below you will find the patch
> >>> which demostrates some of them. In this particular example the problem arises
> >>> due to simultaneous inclusion of some compiler headers along with barebox
> >>> version of `strings.h`, which in turn includes barebox analogs of those headers
> >>> from `include/linux`. I belive there should be a segregation between headers in
> >>> `include` and in `include/linux`, i.e. headers from `include/` should not
> >>> reference <linux/*.h> headers. Yet I understand this is somewhat problematic.
> >>> What do you think?
> >>
> >> barebox code shouldn't make use of any compiler headers at all, except for <stdarg.h>.
> >> The only exception are arch/sandbox/os and scripts/, which reference libc headers.
> >> Everything else should comes out of barebox' include/ directory.
> >>
> >> If you have foreign code that you want to port into barebox, either modify it
> >> to use barebox headers or change the include order when building it to use _local_
> >> versions of the headers it requires.
> > 
> > Ok, I've got your point. Yet I want to point out that addition of *unmodified*
> > code in a form of git submodule would greatly simplify further support of this 
> > port. Unfortunately modifying include order will not help in this case, since, 
> > for example, both `barebox/include/linux/stddef.h` (included from 
> > `barebox/include/string.h` via <linux/string.h>, etc.) and 
> > `/usr/lib/gcc-cross/<ARCH>-linux-gnu/X/include/stdbool.h` define `true`/`false` 
> > macros. On the other hand `/usr/include/linux/stddef.h` and 
> > `/usr/lib/gcc/<ARCH>-linux-gnu/X/include/stdbool.h` coexist in GNU/Linux system 
> > nicely, since no header from `/usr/include/` does reference <linux/*.h> 
> > headers.
> 
> Even if our headers didn't clash, our symbols might. You want to use the
> same declaration/prototype everywhere a symbol is used.
> 
> If you have external code that uses, say, <string.h>. You write your own string.h,
> and ensure it's first in include path for all the code in the HAL (or w/e) directory
> you have. In that file you could have your wrappers and then #include_next <stdio.h>
> if needed.
> 
> If you have global symbols clashing in incompatible ways, you could perhaps
> postprocess the micropython object code with objcopy to give all symbols a
> micropython_ prefix..?
> 
> The proper abstraction is probably to have a module, but that seems only supported
> on ARM.
> 
> >>> diff --git a/commands/types_conflict.c b/commands/types_conflict.c
> >>> new file mode 100644
> >>> index 0000000000..70fee8d6f4
> >>> --- /dev/null
> >>> +++ b/commands/types_conflict.c
> >>> @@ -0,0 +1,12 @@
> >>> +#include <stdbool.h>
> >>> +#include <stdint.h>
> >>> +#include <stddef.h>
> >>> +
> >>> +#include <string.h>
> >>
> >> barebox (except sandbox) is meant to be compiled with freestanding C implementations
> >> that aren't required to provide a <string.h>. So no barebox code should depend on
> >> compiler-provided <string.h>.
> > 
> > Actually `string.h` comes from barebox's `include/` dir, while `std*.h` come 
> > from compiler's include dir. 
> > 
> > 
> > PS: By the way, do you think Barebox will benefit from importing MicroPython 
> > (https://micropython.org/) and exposing some of Barebox APIs to it?
> 
> We have setjmp/longjmp on all architectures now, so it should make porting MicroPython
> easier. I probably wouldn't use it, but I guess it could have some educational value
> for people interested to go from MicroPython + Microcontroller to an
> application processor..?
> 
> It'd be cool to have for sure ;)

Looks like it requires considerable amount of effort, yet no obvious benefit 
for the community is to be achieved, so I opt to abandon it.  

Regards,
Peter

> 
> Cheers,
> Ahmad
> 
> > Regards,
> > Peter
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |