* RFC: types conflicts @ 2020-07-07 13:56 Peter Mamonov 2020-07-08 8:02 ` Ahmad Fatoum 0 siblings, 1 reply; 5+ messages in thread From: Peter Mamonov @ 2020-07-07 13:56 UTC (permalink / raw) To: s.hauer, antonynpavlov; +Cc: barebox, 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: types conflicts 2020-07-07 13:56 RFC: types conflicts Peter Mamonov @ 2020-07-08 8:02 ` Ahmad Fatoum 2020-07-08 21:02 ` Peter Mamonov 0 siblings, 1 reply; 5+ messages in thread From: Ahmad Fatoum @ 2020-07-08 8:02 UTC (permalink / raw) To: Peter Mamonov, s.hauer, antonynpavlov; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: types conflicts 2020-07-08 8:02 ` Ahmad Fatoum @ 2020-07-08 21:02 ` Peter Mamonov 2021-04-19 7:58 ` Ahmad Fatoum 0 siblings, 1 reply; 5+ messages in thread From: Peter Mamonov @ 2020-07-08 21:02 UTC (permalink / raw) To: Ahmad Fatoum; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: types conflicts 2020-07-08 21:02 ` Peter Mamonov @ 2021-04-19 7:58 ` Ahmad Fatoum 2021-04-20 21:47 ` Peter Mamonov 0 siblings, 1 reply; 5+ messages in thread From: Ahmad Fatoum @ 2021-04-19 7:58 UTC (permalink / raw) To: Peter Mamonov; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: types conflicts 2021-04-19 7:58 ` Ahmad Fatoum @ 2021-04-20 21:47 ` Peter Mamonov 0 siblings, 0 replies; 5+ messages in thread From: Peter Mamonov @ 2021-04-20 21:47 UTC (permalink / raw) To: Ahmad Fatoum; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-04-20 21:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-07 13:56 RFC: types conflicts Peter Mamonov 2020-07-08 8:02 ` Ahmad Fatoum 2020-07-08 21:02 ` Peter Mamonov 2021-04-19 7:58 ` Ahmad Fatoum 2021-04-20 21:47 ` Peter Mamonov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox