Commit r15-518-g99b1daae18c095 appears to have uncovered a latent issue in the PRU backend. Many C++ test cases started failing due to a missing symbol: /home/dinux/projects/pru/testbot-workspace/pru-opt/pru/bin/ld: /home/dinux/projects/pru/testbot-workspace/pru-opt/lib/gcc/pru/15.0.0/../../../../pru/lib/libc.a(libc_a-getentropyr.o): in function `_getentropy_r': /home/dinux/projects/pru/testbot-workspace/newlib/newlib/libc/reent/getentropyr.c:47:(.text._getentropy_r+0x28): undefined reference to `_getentropy' collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: g++.dg/coroutines/torture/func-params-08.C (test for excess errors) Indeed, that syscall has not been defined by PRU's libgloss. Naive solutions would be to either enable -gc-sections by default for PRU, or define the getentropy syscall for PRU in newlib. I'm filing this bug report because I'd like to investigate a bit why it used to work before.
Hmm, _GLIBCXX_HAVE_GETENTROPY maybe should not defined for PRU while configuring libstdc++ ...
Before r15-518-g99b1daae18c095, getentropy usage is disabled, as expected: pru-gcc-build/pru/libstdc++-v3/include/pru/bits/c++config.h:/* #undef _GLIBCXX_HAVE_GETENTROPY */ With r15-518-g99b1daae18c095, the generated code appears to be slightly bigger (similar to PR115144). The "hello world" check in config/no-executables.m4 has been already close to the default IMEM limit of 8K, so the link now begins to fail due to IMEM region overflow. Thus the configure script switches to "gcc_no_link=yes". Newlib does not gate the getentropy() function declaration. Hence a simple compile check succeeds and erroneously enables it for libstdc++: pru-gcc-build/pru/libstdc++-v3/include/pru/bits/c++config.h:#define _GLIBCXX_HAVE_GETENTROPY 1 As a fix, I plan to increase the IMEM size in the default linker script.
Fixed in GNU linker by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a606ff9b090a88b19eaf95914618274041f164c4
Closing