RFC: types conflicts

[Ahmad Fatoum]

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 ;)

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 |