RFC: types conflicts

RFC: types conflicts

[Peter Mamonov]

Hello,

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?

Regards,
Peter

---
 commands/Makefile         |  1 +
 commands/types_conflict.c | 12 ++++++++++++
 2 files changed, 13 insertions(+)
 create mode 100644 commands/types_conflict.c

diff --git a/commands/Makefile b/commands/Makefile
index 817fc36e96..4e0cf34560 100644
--- a/commands/Makefile
+++ b/commands/Makefile
@@ -1,3 +1,4 @@
+obj-y				+= types_conflict.o
 obj-$(CONFIG_STDDEV)		+= stddev.o
 obj-$(CONFIG_CMD_DIGEST)	+= digest.o
 obj-$(CONFIG_COMPILE_HASH)	+= hashsum.o
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>
+
+int test(void);
+
+int test()
+{
+	return 0;
+}
-- 
2.24.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: RFC: types conflicts

[Ahmad Fatoum]

Hello Peter,

On 7/7/20 3:56 PM, Peter Mamonov wrote:
> Hello,
> 
> 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.


> 
> Regards,
> Peter
> 
> ---
>  commands/Makefile         |  1 +
>  commands/types_conflict.c | 12 ++++++++++++
>  2 files changed, 13 insertions(+)
>  create mode 100644 commands/types_conflict.c
> 
> diff --git a/commands/Makefile b/commands/Makefile
> index 817fc36e96..4e0cf34560 100644
> --- a/commands/Makefile
> +++ b/commands/Makefile
> @@ -1,3 +1,4 @@
> +obj-y				+= types_conflict.o
>  obj-$(CONFIG_STDDEV)		+= stddev.o
>  obj-$(CONFIG_CMD_DIGEST)	+= digest.o
>  obj-$(CONFIG_COMPILE_HASH)	+= hashsum.o
> 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>.

> +
> +int test(void);
> +
> +int test()
> +{
> +	return 0;
> +}
> 

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: RFC: types conflicts

[Peter Mamonov]

Hello, Ahmad,

On Wed, Jul 08, 2020 at 10:02:00AM +0200, Ahmad Fatoum wrote:
> Hello Peter,
> 
> On 7/7/20 3:56 PM, Peter Mamonov wrote:
> > Hello,
> > 
> > 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.

> > 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?

Regards,
Peter

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: 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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: 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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox