mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* 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