Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libgcc: C11 threads-based gthread support cannot link samples/cpp/hello_world out-of-the-box #751

Open
Tracked by #25569
cfriedt opened this issue May 1, 2024 · 6 comments
Assignees
Labels
area: libstdc++ Issues related to libstdc++ (GNU C++ Library) enhancement priority: low Low impact/importance issue

Comments

@cfriedt
Copy link
Member

cfriedt commented May 1, 2024

Just test-driving the v0.16.6 SDK, and it looks like samples/cpp/hello_world does not build and run OOTB.

Moving from v0.16.5-1 to 0.16.6, I needed to additionally enable the following in order for the app to link.

CONFIG_COMMON_LIBC_THRD=y
CONFIG_POSIX_API=y
CONFIG_DYNAMIC_THREAD=y
CONFIG_THREAD_STACK_INFO=y

One possible solution for the above would be to create weak versions of the C11 <thread.h> functions in the toolchain, such that linking to an external implementation will provided the necessary functionality (when required).

Since samples/cpp/hello_world does not require C++11 threading, this seems like it would be a good choice.

Beyond that, a couple of additional platforms are now facing issues

qemu_riscv64 and qemu_riscv32

[142/143] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv64
*** Booting Zephyr OS build v3.6.0-3273-g40a8022e4a14 ***
abort()
[142/143] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv32
*** Booting Zephyr OS build v3.6.0-3273-g40a8022e4a14 ***
abort()

This is likely due to something like stack unwinding, but it will take additional effort to diagnose / remedy.

Otherwise, qemu_x86_64, qemu_cortex_a53, qemu_cortex_m3 have been tested with the command below

west build -p -b qemu_cortex_m3 -t run samples/cpp/hello_world \
  -- \
  -DCONFIG_COMMON_LIBC_THRD=y \
  -DCONFIG_POSIX_API=y \
  -DCONFIG_DYNAMIC_THREAD=y \
  -DCONFIG_THREAD_STACK_INFO=y
@cfriedt cfriedt added the area: libstdc++ Issues related to libstdc++ (GNU C++ Library) label May 1, 2024
@cfriedt cfriedt self-assigned this May 1, 2024
@stephanosio stephanosio added bug priority: high High impact/importance issue labels May 5, 2024
@stephanosio
Copy link
Member

This effectively renders the SDK 0.16.6 release unusable until the C11 threads stub functions are added to the Zephyr main branch.

Also, this is a breaking change that creates an incompatibility between the SDK 0.16.6 release and any Zephyr releases prior to the upcoming 3.7.0, which we do not want at this point.

This should have been caught earlier and addressed in a more self-contained way within the SDK (e.g. providing weak C11 threads stub functions within the libgcc itself); unfortunately, the SDK CI does not build and run the C++ tests and samples and this was not caught -- I am going to fix that by adding more tests to be run in the SDK CI.

At this point, I will need to mark the 0.16.6 a bad release and release 0.16.7 without the libstdc++ C11 gthread patch. The libstdc++ patch will need to be reworked to handle the transition more gracefully (as mentioned above, by providing weak C11 threads stubs).

stephanosio added a commit to stephanosio/zephyr-sdk-ng that referenced this issue May 6, 2024
This reverts commit 8dee616 because it
causes incompatibility with prior Zephyr releases which we do not want
at this point.

The relevant GCC patches should be reworked to be more self-contained
and maintain compatibility with prior Zephyr releases as noted in the
GitHub issue zephyrproject-rtos#751.

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
stephanosio added a commit that referenced this issue May 7, 2024
This reverts commit 8dee616 because it
causes incompatibility with prior Zephyr releases which we do not want
at this point.

The relevant GCC patches should be reworked to be more self-contained
and maintain compatibility with prior Zephyr releases as noted in the
GitHub issue #751.

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@stephanosio stephanosio added enhancement priority: low Low impact/importance issue and removed bug priority: high High impact/importance issue labels May 7, 2024
@stephanosio stephanosio changed the title v0.16.6 cannot link samples/cpp/hello_world out-of-the-box libgcc: C11 threads-based gthread support cannot link samples/cpp/hello_world out-of-the-box May 7, 2024
@stephanosio
Copy link
Member

Marking it as an enhancement instead of a bug since 0.16.7 has been released without the C11 threads-based gthread libgcc patch.

@cfriedt
Copy link
Member Author

cfriedt commented May 9, 2024

This effectively renders the SDK 0.16.6 release unusable until the C11 threads stub functions are added to the Zephyr main branch.

We likely do not want stub or weak implementations in Zephyr itself since there is a concrete implementation already.

Also, this is a breaking change that creates an incompatibility between the SDK 0.16.6 release and any Zephyr releases prior to the upcoming 3.7.0, which we do not want at this point.

I would definitely prefer to get this in prior to v3.7.0, since it's already been ~ 2 LTS release cycles in the making.

This should have been caught earlier and addressed in a more self-contained way within the SDK (e.g. providing weak C11 threads stub functions within the libgcc itself); unfortunately, the SDK CI does not build and run the C++ tests and samples and this was not caught -- I am going to fix that by adding more tests to be run in the SDK CI.

Agreed and good idea.

@markaj-nordic
Copy link

markaj-nordic commented May 10, 2024

FYI:
After switching to the 0.16.6, without any tweaks, our C++ Matter applications won't build (due to the linkage issue):

/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::init_static_cond()': guard.cc:(.text._ZN12_GLOBAL__N_1L16init_static_condEv+0x6): undefined reference to cnd_init'
/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::init()': guard.cc:(.text._ZN12_GLOBAL__N_1L4initEv+0x8): undefined reference to mtx_init'
/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::mutex_wrapper::~mutex_wrapper() [clone .isra.0]': guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperD2Ev.isra.0+0xa): undefined reference to mtx_unlock'
/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function (anonymous namespace)::mutex_wrapper::mutex_wrapper() [clone .isra.0]': guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperC2Ev.isra.0+0xa): undefined reference to call_once'
/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text._ZN12_GLOBAL__N_113mutex_wrapperC2Ev.isra.0+0x12): undefined reference to mtx_lock' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __gnu_cxx::__cond::broadcast()':
guard.cc:(.text._ZN9__gnu_cxx6__cond9broadcastEv[_ZN9__gnu_cxx6__cond9broadcastEv]+0x2): undefined reference to cnd_broadcast' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __cxa_guard_acquire':
guard.cc:(.text.__cxa_guard_acquire+0x2c): undefined reference to call_once' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text.__cxa_guard_acquire+0x36): undefined reference to call_once'
/home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: guard.cc:(.text.__cxa_guard_acquire+0x40): undefined reference to cnd_wait' /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /home/marcin/zephyr-sdk-0.16.6/arm-zephyr-eabi/arm-zephyr-eabi/lib/thumb/v7e-m+fp/hard/libstdc++_nano.a(guard.o): in function __cxa_guard_release':
guard.cc:(.text.__cxa_guard_release+0x1a): undefined reference to `call_once'

Any ETA for 0.16.7 release? I see the tag is already there.

@seyednasermoravej
Copy link

Hi, I'm facing the same issue as @markaj-nordic mentioned.
Any progress of instructions to solve this issue?
Tnx

@cfriedt
Copy link
Member Author

cfriedt commented Jun 8, 2024

@seyednasermoravej use 0.16.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: libstdc++ Issues related to libstdc++ (GNU C++ Library) enhancement priority: low Low impact/importance issue
Projects
None yet
Development

No branches or pull requests

4 participants