arm-none-eabi-toolchain atomic support is broken

  • Open
  • quality assurance status badge
Details
3 participants
  • Jean Pierre De Jesus DIAZ
  • Csepp
  • Rutherther
Owner
unassigned
Submitted by
Jean Pierre De Jesus DIAZ
Severity
normal
J
J
Jean Pierre De Jesus DIAZ wrote on 10 Aug 2022 13:14
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
FxrTtbkN-kgBnsg2G8jk10dUAf5LGSIhQQKxosEukaNtGlCbHPCXA3HyNf6hzdYYe-qIRF6DlER0-Ma2XjMmzN8GDcwYPNP-5LylnDLavcY=@jeandudey.tech
The atomic supports for this toolchain is broken:

A minimal test case:

guix shell arm-none-eabi-toolchain -- \
bash -c "echo '#include <stdatomic.h>' \
| arm-none-eabi-gcc -x c -o /dev/null -c -"

Something similar found online:


However no solution.

This happens with all versions of the arm-none-eabi-toolchain
packages.

—
Jean-Pierre De Jesus DIAZ
J
J
Jean Pierre De Jesus DIAZ wrote on 16 Aug 2022 16:14
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
W3bwtjXOE9kR8_Y5FAONpXogV-HS5-FwbXBLauTFI0N5PN6CVuez0dh2ToQBJGSb02mCOLJ0CPotmEtWG-1LbWZON4no9bk6H1yqT4yeh10=@jeandudey.tech
The following works though. No newlib or anything:

guix shell --expression='((@ (gnu packages cross-base) cross-gcc) "arm-none-eabi")' -- \
bash -c "echo '#include <stdatomic.h>' \
| arm-none-eabi-gcc -x c -o /dev/null -c -"


—
Jean-Pierre De Jesus DIAZ


------- Original Message -------
On Wednesday, August 10th, 2022 at 1:14 PM, Jean Pierre De Jesus DIAZ <me@jeandudey.tech> wrote:


Toggle quote (20 lines)
> The atomic supports for this toolchain is broken:
>
> A minimal test case:
>
> guix shell arm-none-eabi-toolchain -- \
> bash -c "echo '#include <stdatomic.h>' \
>
> | arm-none-eabi-gcc -x c -o /dev/null -c -"
>
> Something similar found online:
>
> https://sourceware.org/legacy-ml/newlib/2017/msg00150.html
>
> However no solution.
>
> This happens with all versions of the arm-none-eabi-toolchain
> packages.
>
> —
> Jean-Pierre De Jesus DIAZ
C
C
Csepp wrote on 18 Aug 2022 16:24
Re: bug#57109: arm-none-eabi-toolchain atomic support is broken
(name . Jean Pierre De Jesus DIAZ)(address . me@jeandudey.tech)
878rnlbpbe.fsf@riseup.net
Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (36 lines)
> The following works though. No newlib or anything:
>
> guix shell --expression='((@ (gnu packages cross-base) cross-gcc) "arm-none-eabi")' -- \
> bash -c "echo '#include <stdatomic.h>' \
> | arm-none-eabi-gcc -x c -o /dev/null -c -"
>
>
> —
> Jean-Pierre De Jesus DIAZ
>
>
> ------- Original Message -------
> On Wednesday, August 10th, 2022 at 1:14 PM, Jean Pierre De Jesus DIAZ <me@jeandudey.tech> wrote:
>
>
>> The atomic supports for this toolchain is broken:
>>
>> A minimal test case:
>>
>> guix shell arm-none-eabi-toolchain -- \
>> bash -c "echo '#include <stdatomic.h>' \
>>
>> | arm-none-eabi-gcc -x c -o /dev/null -c -"
>>
>> Something similar found online:
>>
>> https://sourceware.org/legacy-ml/newlib/2017/msg00150.html
>>
>> However no solution.
>>
>> This happens with all versions of the arm-none-eabi-toolchain
>> packages.
>>
>> —
>> Jean-Pierre De Jesus DIAZ

Might be a good idea to add a (regression) test for this in advance.
Wish I could help, but my expermientation with cross compilation with
Guix were largely fruitless.
R
R
Rutherther wrote on 8 Sep 11:26 +0200
Re: arm-none-eabi-toolchain atomic support is broken
(address . 57109@debbugs.gnu.org)
877cbmv6mj.fsf@protonmail.com
Toggle quote (13 lines)
> Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>
> > The following works though. No newlib or anything:
> >
> > guix shell --expression='((@ (gnu packages cross-base) cross-gcc) "arm-none-eabi")' -- \
> > bash -c "echo '#include <stdatomic.h>' \
> > | arm-none-eabi-gcc -x c -o /dev/null -c -"
> >
> >
> > —
> > Jean-Pierre De Jesus DIAZ
> >

The reason this works is that the stdatomic.h is used from gcc itself,
instead of the stdatomic.h coming from newlib. It works even with the
arm-none-eabi gcc's coming from `gnu packages embedded`.

The newlib one seems to be broken, though I am unable to find any
discussion on newlib's part. I've tried toolchain coming from
developer.arm.com directly (through nixpkgs that packages the binaries)
and found out that they use stdatomic.h coming from gcc even in full toolchain.

The problem in the Guix ones is that since those use
CROSS_C_INCLUDE_PATH. The paths here get priority to the ones coming from gcc
itself. This then means the newlib stdatomic.h shadows the one coming
from (arm-none-eabi-)gcc:lib.

The toolchain from developer.arm.com does not have this issue, since it
relies on the paths directly from gcc, having the one with newlib as
last. When I try directly including stdatomic.h from newlib, I also
get this error even with that toolchain.

A solution could be to prepend the include path from gcc:lib into the
CROSS_C_INCLUDE_PATH to make it take priority, and prefer the packages
coming from there, or to stop relying on the env vars.

See the toolchain from Nix, the one not using env vars:
```
#include <...> search starts here:
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/include
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/include-fixed
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/include
```

See Guix one:
```
#include <...> search starts here:
/gnu/store/h5jxagsf8236ff3lbfcd4yk1qhk2bs4p-profile/arm-none-eabi/include
/gnu/store/pjc5ysriqs6w99ihkza7xgwm8clfpgp0-gcc-cross-sans-libc-arm-none-eabi-7-2018-q2-update-1.261907-lib/lib/gcc/arm-none-eabi/7.3.1/include
/gnu/store/pjc5ysriqs6w99ihkza7xgwm8clfpgp0-gcc-cross-sans-libc-arm-none-eabi-7-2018-q2-update-1.261907-lib/lib/gcc/arm-none-eabi/7.3.1/include-fixed
```

Regards,
Rutherther
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 57109@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 57109
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch