[committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Hans-Peter Nilsson]

As you've seen in other patch submissions, there was recently a change
in gcc such that implicit function declarations and type mismatches
are now errors, no longer just warnings.

Problems are in port-specific code, as I don't see any breakage for
arm-eabi.  Patches for some other ports are in, and I guess lots more
will trickle in as port maintainers and other people find out and fix.
This two-set of patches handles newlib and libgloss for cris-elf.

A gcc regtest round shows no regressions compared to before the
"breaking" gcc commit.  Caveat: a patch-set adding a _getentropy stub
from August (IIRC) causes lots of FAILs; some of those are worked
around in gcc to get better coverage.  Film at 11.  Anyway, a
regtest-round with these patches applied to a newlib checkout before
the _getentropy patches shows no regressions for cris-elf+cris-sim,
and working around *some* of the breakage with a slightly more recent
newlib checkout (dab15f6740ff) shows that to be the only issue.

brgds, H-P

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Torbjorn SVENSSON]

Hi Hans-Peter,

On 2023-12-06 18:50, Hans-Peter Nilsson wrote:
> Caveat: a patch-set adding a _getentropy stub
> from August (IIRC) causes lots of FAILs; some of those are worked
> around in gcc to get better coverage.

What problems are there with the _getentropy stubs that I've submitted?

Kind regards,
Torbjörn

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Hans-Peter Nilsson]

> Date: Wed, 6 Dec 2023 20:52:48 +0100
> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>

(Sorry for the late reply: the newlib mailer appears to have
directed your mail only to the newlib without even a CC to
me, so your reply got into my newlib folder, unfortunately
not visited daily.)

> Hi Hans-Peter,
> 
> On 2023-12-06 18:50, Hans-Peter Nilsson wrote:
> > Caveat: a patch-set adding a _getentropy stub
> > from August (IIRC) causes lots of FAILs; some of those are worked
> > around in gcc to get better coverage.
> 
> What problems are there with the _getentropy stubs that I've submitted?

I hope to get into details later, as indicated by the "film
at 11".  The problem is fairly visible with a standard
test-run for cris-elf (with simulator and baseboard
cris-sim): all libstdc++ tests fail with a linker warning,
as its configure tests detect a presence of _getentropy but
its reference trigs the stub warning (the .gnu.warning
thing).  I *think* it's also visible for a build with
arm-eabi+arm-sim which made me wonder how you configured and
tested (you may have stated, I haven't looked).  Adding a
patch to "prune" the stub-warning in libstdc++ prune.exp
only exposes runtime errors when _getentropy is actually
called.  Those errors are not present when _getentropy is
not detected (and not used).

Looks like I managed to actually state the gist of the
problem.  Missing are details such as (todo) proposed best
actions, besides reverting that patch, to better handle the
problem *you* say.  That's also all I can say for now.

Feel very free to wait until I come back to this: I can't
focus on this issue right now; just thought I'd reply with
what state I have at the top of my head, since you asked.
Sorry!

brgds, H-P

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Torbjorn SVENSSON]

Hello Hans-Peter,

I finally had some time to go back to this topic.

On 2023-12-15 05:24, Hans-Peter Nilsson wrote:
>> Date: Wed, 6 Dec 2023 20:52:48 +0100
>> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
>> What problems are there with the _getentropy stubs that I've submitted?
> 
> I hope to get into details later, as indicated by the "film
> at 11".  The problem is fairly visible with a standard
> test-run for cris-elf (with simulator and baseboard
> cris-sim): all libstdc++ tests fail with a linker warning,
> as its configure tests detect a presence of _getentropy but
> its reference trigs the stub warning (the .gnu.warning
> thing).  I *think* it's also visible for a build with
> arm-eabi+arm-sim which made me wonder how you configured and
> tested (you may have stated, I haven't looked).  Adding a
> patch to "prune" the stub-warning in libstdc++ prune.exp
> only exposes runtime errors when _getentropy is actually
> called.  Those errors are not present when _getentropy is
> not detected (and not used).


When I run the tests, I supply all the syscalls functions in my fixture 
to avoid the stubs warnings. This is nothing new to the _getentropy 
function though as the same problem is visible with for example _close.

If I try to link the following minimal C application with the 
arm-none-eabi target, I get the below warnings.

$ cat foo.c
int main() {
     return 0;
}


$ .../bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mfloat-abi=soft -o foo.elf 
foo.c --specs=nosys.specs
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-closer.o): 
in function `_close_r':
(.text._close_r+0xc): warning: _close is not implemented and will always 
fail
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-lseekr.o): 
in function `_lseek_r':
(.text._lseek_r+0x10): warning: _lseek is not implemented and will 
always fail
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-readr.o): 
in function `_read_r':
(.text._read_r+0x10): warning: _read is not implemented and will always fail
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
.../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-writer.o): 
in function `_write_r':
(.text._write_r+0x10): warning: _write is not implemented and will 
always fail


Do you mean that you do not get these stub warnings for the cris-elf target?
If you do get them, in what way is _getentropy different from for 
example _close?

(the above is produced using newlib 7a45daa, GCC d0603dfe9 and binutils 
80d2ef0c4)

Kind regards,
Torbjörn

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Hans-Peter Nilsson]

> Date: Thu, 21 Dec 2023 18:37:14 +0100
> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>

> Hello Hans-Peter,

Hi.

> I finally had some time to go back to this topic.

I don't have time to dig into this just yet.  As I mentioned
before, I'll get back to you, please be patient.

I'll still answer your questions below even though I fear
they lead off into a tangent.  I'll get back to this and add
a proposed solution.  Until then:

> On 2023-12-15 05:24, Hans-Peter Nilsson wrote:
> >> Date: Wed, 6 Dec 2023 20:52:48 +0100
> >> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
> >> What problems are there with the _getentropy stubs that I've submitted?
> > 
> > I hope to get into details later, as indicated by the "film
> > at 11".  The problem is fairly visible with a standard
> > test-run for cris-elf (with simulator and baseboard
> > cris-sim): all libstdc++ tests fail with a linker warning,
> > as its configure tests detect a presence of _getentropy but
> > its reference trigs the stub warning (the .gnu.warning
> > thing).  I *think* it's also visible for a build with
> > arm-eabi+arm-sim which made me wonder how you configured and
> > tested (you may have stated, I haven't looked).  Adding a
> > patch to "prune" the stub-warning in libstdc++ prune.exp
> > only exposes runtime errors when _getentropy is actually
> > called.  Those errors are not present when _getentropy is
> > not detected (and not used).
> 
> 
> When I run the tests, I supply all the syscalls functions in my fixture 
> to avoid the stubs warnings. This is nothing new to the _getentropy 
> function though as the same problem is visible with for example _close.

Not sure I get you here.  If your "fixture" doesn't do that
for _close, you haven't implemented a proper syscall
function for _close.

But, you shouldn't have to add special machinery, it should
already be there in your dejagnu baseboard file.

Care to share it?  What simulator are you targetting?  The
arm-sim in the gdb project notoriously doesn't support
anything but the default GCC target, not -mcpu=cortex-m4, so
I think you don't test with 'make check
RUNTESTFLAGS=--target_board=arm-sim', i.e. not with the
arm-sim.exp provided by dejagnu, right?

To wit, if you use something that gives other results than
when configuring for --target=arm-eabi and testing with
RUNTESTFLAGS=--target_board=arm-sim then your gcc testing
isn't matching the expectations in libstdc++-v3 for a newlib
target (IOW "not correct").

Some outdated information which should still help you get a
working environment is in gcc.gnu.org/simtest-howto.html
(but I suggest build and install sim+binutils separately,
with just newlib and gcc combined).

> If I try to link the following minimal C application with the 
> arm-none-eabi target, I get the below warnings.
> 
> $ cat foo.c
> int main() {
>      return 0;
> }
> 
> 
> $ .../bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mfloat-abi=soft -o foo.elf 
> foo.c --specs=nosys.specs
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-closer.o): 
> in function `_close_r':
> (.text._close_r+0xc): warning: _close is not implemented and will always 
> fail
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-lseekr.o): 
> in function `_lseek_r':
> (.text._lseek_r+0x10): warning: _lseek is not implemented and will 
> always fail
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-readr.o): 
> in function `_read_r':
> (.text._read_r+0x10): warning: _read is not implemented and will always fail
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld: 
> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-writer.o): 
> in function `_write_r':
> (.text._write_r+0x10): warning: _write is not implemented and will 
> always fail
> 
> 
> Do you mean that you do not get these stub warnings for the cris-elf target?

(When *configuring* libstdc++ I'd get those warnings, that's
why linking tests are disabled for newlib there.)

But, when called as part of the testsuite, *no*: not with a
proper syscall library, such as when "-sim3" is passed when
linking (see the libsyslinux.a stuff in libgloss/cris and
e.g. LIB_SPEC in gcc/config/cris/cris.h), as happens when
running with --target_board=cris-sim.

Don't arm-eabi+arm-sim get lots of libstdc++-v3 errors that
weren't there before your newlib _getentropy patch?

Can you share your full environment such that I can repeat
your observations?

> If you do get them, in what way is _getentropy different from for 
> example _close?

_close is implemented in libsyslinux.a, _getentropy not.
(No syscall for that so the stub warning is "correct".)

> (the above is produced using newlib 7a45daa, GCC d0603dfe9 and binutils 
> 80d2ef0c4)

Again, all my observations are repeatable by anyone:
- Install binutils for --target=cris-elf --prefix=<whatever>
- Ditto the cris simulator in gdb.
- Configure a "combined" tree with gcc and newlib.
- Build gcc+newlib using the same --target=cris-elf --prefix=<whatever>
- 'make check RUNTESTFLAGS=--target_board=cris-sim'.
- Observe the multitude of libstdc++-v3 tests failing that
weren't there before your _getentropy patch.

Please share your full testing environment such that I can
repeat your observations.

I'll get back with a proper solution, one where
arm-eabi+arm-sim, cris-elf+cris-sim and your own environment
all work (hopefully, or help you get a proper testing
environment), before next summer.

brgds, H-p

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Torbjorn SVENSSON]

On 2023-12-21 19:26, Hans-Peter Nilsson wrote:
>> Date: Thu, 21 Dec 2023 18:37:14 +0100
>> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
> 
>> Hello Hans-Peter,
> 
> Hi.
> 
>> I finally had some time to go back to this topic.
> 
> I don't have time to dig into this just yet.  As I mentioned
> before, I'll get back to you, please be patient.
> 
> I'll still answer your questions below even though I fear
> they lead off into a tangent.  I'll get back to this and add
> a proposed solution.  Until then:
> 
>> On 2023-12-15 05:24, Hans-Peter Nilsson wrote:
>>>> Date: Wed, 6 Dec 2023 20:52:48 +0100
>>>> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
>>>> What problems are there with the _getentropy stubs that I've submitted?
>>>
>>> I hope to get into details later, as indicated by the "film
>>> at 11".  The problem is fairly visible with a standard
>>> test-run for cris-elf (with simulator and baseboard
>>> cris-sim): all libstdc++ tests fail with a linker warning,
>>> as its configure tests detect a presence of _getentropy but
>>> its reference trigs the stub warning (the .gnu.warning
>>> thing).  I *think* it's also visible for a build with
>>> arm-eabi+arm-sim which made me wonder how you configured and
>>> tested (you may have stated, I haven't looked).  Adding a
>>> patch to "prune" the stub-warning in libstdc++ prune.exp
>>> only exposes runtime errors when _getentropy is actually
>>> called.  Those errors are not present when _getentropy is
>>> not detected (and not used).
>>
>>
>> When I run the tests, I supply all the syscalls functions in my fixture
>> to avoid the stubs warnings. This is nothing new to the _getentropy
>> function though as the same problem is visible with for example _close.
> 
> Not sure I get you here.  If your "fixture" doesn't do that
> for _close, you haven't implemented a proper syscall
> function for _close.
> 
> But, you shouldn't have to add special machinery, it should
> already be there in your dejagnu baseboard file.

The baseboard file *is* the fixture.

> Care to share it?  What simulator are you targetting?  The
> arm-sim in the gdb project notoriously doesn't support
> anything but the default GCC target, not -mcpu=cortex-m4, so
> I think you don't test with 'make check
> RUNTESTFLAGS=--target_board=arm-sim', i.e. not with the
> arm-sim.exp provided by dejagnu, right?

I'm using a combination of real evaluation boards and the qemu simulator.
Unfortunately, I cannot share it as it's tied to how the internal 
systems are setup at ST.

What I can share is the overall setup and that is:

1. Running a patched qemu that just adds custom machine that has the 
same address layout as a real STM32 device so that I can take the same 
binary and run it on real hardware in order to verify if a failure is 
due to qemu or if it's a real problem.
The flags used to run qemu-system-arm varies with the target, but for 
Cortex-M4, it would be:
qemu-system-arm -nographic -machine <the-custom-qemu-machine> -cpu 
cortex-m4 -semihosting -monitor /dev/null -kernel <image.elf>

2. The baseboard file defines some flags:
cflags: "[libgloss_include_flags] [newlib_include_flags]"
ldflags: " -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs 
-Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat"

It also adds a set of object files to link into the elf file that 
contains a custom startup code (aligned with qemu and real STM32 
targets) and the following functions:

* __initialize_args
* _clock
* _close
* _execve
* _exit
* _fork
* _getentropy
* _getpid
* _gettimeofday
* _isatty
* _kill
* _link
* _lseek
* _open
* _read
* _rename
* _sbrk
* _stat
* _swiclose
* _swilseek
* _swiopen
* _swiread
* _swistat
* _swiwrite
* _system
* _times
* _unlink
* _wait
* _write
* getcwd
* initialise_monitor_handles
* mkdir

And then finally, it uses a custom ldscript that matches the 
requirements for STM32 targets.

3. The qemu execution is always performed on a Linux system regardless 
if the dejagnu tests are executed on Windows, Linux or mac. This is to 
ensure that the qemu process does not introduce platform variations and 
makes the test results comparable between the platforms runs.

> To wit, if you use something that gives other results than
> when configuring for --target=arm-eabi and testing with
> RUNTESTFLAGS=--target_board=arm-sim then your gcc testing
> isn't matching the expectations in libstdc++-v3 for a newlib
> target (IOW "not correct").

I'm pretty sure it didn't match the expectations before either as it 
picked up the header definition for _getentropy during the configure 
stage, but when linking, there was no such function defined in the 
newlib provided archives, thus the following error (taken from the 
commit message of b9e867d088935d9f0bf312e6dbf3e4976850dfd3) was raised 
during testing of the g++ tool:

 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/bin/ld: 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libstdc++.a(random.o): 
in function `std::(anonymous namespace)::__libc_getentropy(void*)':
     (.text._ZNSt12_GLOBAL__N_117__libc_getentropyEPv+0x8): undefined 
reference to `getentropy'
 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/bin/ld: 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libstdc++.a(random.o): 
in function 
`std::random_device::_M_init(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const&)':
 
(.text._ZNSt13random_device7_M_initERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x58): 
undefined reference to `getentropy'
 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/bin/ld: 
/build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(libc_a-arc4random.o): 
in function `_rs_stir':
     (.text._rs_stir+0x8): undefined reference to `getentropy'
     collect2: error: ld returned 1 exit status

This error was fixed with newlib supplying the getentropy function that 
behaves just like the others by calling the low level function _getentropy.


> Some outdated information which should still help you get a
> working environment is in gcc.gnu.org/simtest-howto.html
> (but I suggest build and install sim+binutils separately,
> with just newlib and gcc combined).
> 
>> If I try to link the following minimal C application with the
>> arm-none-eabi target, I get the below warnings.
>>
>> $ cat foo.c
>> int main() {
>>       return 0;
>> }
>>
>>
>> $ .../bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mfloat-abi=soft -o foo.elf
>> foo.c --specs=nosys.specs
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld:
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-closer.o):
>> in function `_close_r':
>> (.text._close_r+0xc): warning: _close is not implemented and will always
>> fail
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld:
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-lseekr.o):
>> in function `_lseek_r':
>> (.text._lseek_r+0x10): warning: _lseek is not implemented and will
>> always fail
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld:
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-readr.o):
>> in function `_read_r':
>> (.text._read_r+0x10): warning: _read is not implemented and will always fail
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld:
>> .../bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_a-writer.o):
>> in function `_write_r':
>> (.text._write_r+0x10): warning: _write is not implemented and will
>> always fail
>>
>>
>> Do you mean that you do not get these stub warnings for the cris-elf target?
> 
> (When *configuring* libstdc++ I'd get those warnings, that's
> why linking tests are disabled for newlib there.)

That sounds strange. This is what I get when configuring libstdc++ for 
arm-none-eabi:

configure:51567: checking for getentropy
configure:51586: .../build-native/gcc-final/./gcc/xgcc -shared-libgcc 
-B.../build-native/gcc-final/./gcc -nostdinc++ 
-L.../build-native/gcc-final/arm-none-eabi/thumb/v7e-m/nofp/libstdc++-v3/src 
-L.../build-native/gcc-final/arm-none-eabi/thumb/v7e-m/nofp/libstdc++-v3/src/.libs 
-L.../build-native/gcc-final/arm-none-eabi/thumb/v7e-m/nofp/libstdc++-v3/libsupc++/.libs 
-B.../install-native/arm-none-eabi/bin/ 
-B.../install-native/arm-none-eabi/lib/ -isystem 
.../install-native/arm-none-eabi/include -isystem 
.../install-native/arm-none-eabi/sys-include  -mthumb -march=armv7e-m 
-mfloat-abi=soft -c -g -O2  conftest.cpp >&5
configure:51586: $? = 0
configure:51618: result: yes

(this is from 
.../build-native/gcc-final/arm-none-eabi/thumb/v7e-m/nofp/libstdc++-v3/config.log).


> But, when called as part of the testsuite, *no*: not with a
> proper syscall library, such as when "-sim3" is passed when
> linking (see the libsyslinux.a stuff in libgloss/cris and
> e.g. LIB_SPEC in gcc/config/cris/cris.h), as happens when
> running with --target_board=cris-sim.

In my case (cross building and cross testing) is that without my patch, 
the failure happens in the testsuite.

> Don't arm-eabi+arm-sim get lots of libstdc++-v3 errors that
> weren't there before your newlib _getentropy patch?

I don't use arm-sim, so I don't know.

> Can you share your full environment such that I can repeat
> your observations?
> 
>> If you do get them, in what way is _getentropy different from for
>> example _close?
> 
> _close is implemented in libsyslinux.a, _getentropy not.
> (No syscall for that so the stub warning is "correct".)

So, in that case, just add the following to the library? It should be 
enough to make your simulator happy and it can still be overridden when 
using newlib built for the cris architecture in real applications.

int _getentropy(void *buf, size_t buflen)
{
   errno = ENOSYS;
   return -1;
}

>> (the above is produced using newlib 7a45daa, GCC d0603dfe9 and binutils
>> 80d2ef0c4)
> 
> Again, all my observations are repeatable by anyone:
> - Install binutils for --target=cris-elf --prefix=<whatever>
> - Ditto the cris simulator in gdb.
> - Configure a "combined" tree with gcc and newlib.
> - Build gcc+newlib using the same --target=cris-elf --prefix=<whatever>
> - 'make check RUNTESTFLAGS=--target_board=cris-sim'.
> - Observe the multitude of libstdc++-v3 tests failing that
> weren't there before your _getentropy patch.
> 
> Please share your full testing environment such that I can
> repeat your observations.

As I wrote above, I can't do that as it's tied to the ST infra.

> I'll get back with a proper solution, one where
> arm-eabi+arm-sim, cris-elf+cris-sim and your own environment
> all work (hopefully, or help you get a proper testing
> environment), before next summer.
> 
> brgds, H-p

Looking forward to your "proper solution" as this appears to work fine 
if you just define the low level implementation for your architecture.

Kind regards,
Torbjörn

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Hans-Peter Nilsson]

Half-way through your mail, I thought better put this
together.  It doesn't address all of it though.

> Date: Sat, 23 Dec 2023 11:58:42 +0100
> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>

> I'm using a combination of real evaluation boards and the qemu simulator.

(and a patched qemu, IIUC)

> Unfortunately, I cannot share it as it's tied to how the internal 
> systems are setup at ST.

That's very unfortunate.

> > To wit, if you use something that gives other results than
> > when configuring for --target=arm-eabi and testing with
> > RUNTESTFLAGS=--target_board=arm-sim then your gcc testing
> > isn't matching the expectations in libstdc++-v3 for a newlib
> > target (IOW "not correct").
> 
> I'm pretty sure it didn't match the expectations before

(Well, it did, for cris-elf+cris-sim.  I still have to check
whether something was actually missing for
arm-eabi+arm-sim.)

> either as it 
> picked up the header definition for _getentropy during the configure 
> stage,

Confusion.  There was no _getentropy (or getentropy) before
you added it, so how could it be picked up?  Not ruling out
bugs in libstdc++-v3 configuration here.  Maybe it didn't
recognize your mix as a newlib target?  (It should default
to it from the target tuple, but you can always add a
--with-newlib.)

If you didn't post your complete configure line and
config.log in previous reports and conversions to newlib@
and gcc lists, please do.

> but when linking, there was no such function defined in the 
> newlib provided archives, thus the following error (taken from the 
> commit message of b9e867d088935d9f0bf312e6dbf3e4976850dfd3) was raised 
> during testing of the g++ tool:
> 
>  
> /build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/bin/ld: 
> /build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libstdc++.a(random.o): 
> in function `std::(anonymous namespace)::__libc_getentropy(void*)':
>      (.text._ZNSt12_GLOBAL__N_117__libc_getentropyEPv+0x8): undefined 
> reference to `getentropy'

Right; that means it was *wrongly* identified as present at
configure-time.  The solution is then not to add a stub, but
to fix the wrong present-identification.

> In my case (cross building and cross testing) is that without my patch, 
> the failure happens in the testsuite.

Odd; I'll re-read that conversion.  The lack of _getentropy
(and getentropy) before, *should* not have posed any problem.

> So, in that case, just add the following to the library? It should be 
> enough to make your simulator happy and it can still be overridden when 
> using newlib built for the cris architecture in real applications.
> 
> int _getentropy(void *buf, size_t buflen)
> {
>    errno = ENOSYS;
>    return -1;
> }
> 

That won't fly.  I mentioned that pruning the stub warning
exposes runtime errors, so that'll lead to *regressions for
those libstdc++ tests that expect randomness support to
work, compared to before the _getentropy stub*.  (Before,
libstdc++ fell back to to another randomness
implementation.)

> Looking forward to your "proper solution" as this appears to work fine 
> if you just define the low level implementation for your architecture.

A proper solution is one that matches what's actually
implemented in newlib and libgloss.

It worked before the _getentropy stub, it fails afterwards.

IMHO it's preferable to target off-the-shelf buildable
toolchain combinations rather than homegrown collections; if
the latter work, then fine, but if they break what's already
there, then that collection should be adjusted, not the rest
of newlib+libgloss.

Of course, there may be a working combination for both.

Merry Xmas.

brgds, H-P

Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors

[Torbjorn SVENSSON]

On 2023-12-23 17:44, Hans-Peter Nilsson wrote:
> Half-way through your mail, I thought better put this
> together.  It doesn't address all of it though.
> 
>> Date: Sat, 23 Dec 2023 11:58:42 +0100
>> From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
> 
>> I'm using a combination of real evaluation boards and the qemu simulator.
> 
> (and a patched qemu, IIUC)

The patch is only to add a machine definition in qemu that has a 
matching address space. It has no impact on the instructions executed.

>> Unfortunately, I cannot share it as it's tied to how the internal
>> systems are setup at ST.
> 
> That's very unfortunate.
> 
>>> To wit, if you use something that gives other results than
>>> when configuring for --target=arm-eabi and testing with
>>> RUNTESTFLAGS=--target_board=arm-sim then your gcc testing
>>> isn't matching the expectations in libstdc++-v3 for a newlib
>>> target (IOW "not correct").
>>
>> I'm pretty sure it didn't match the expectations before
> 
> (Well, it did, for cris-elf+cris-sim.  I still have to check
> whether something was actually missing for
> arm-eabi+arm-sim.)
> 
>> either as it
>> picked up the header definition for _getentropy during the configure
>> stage,
> 
> Confusion.  There was no _getentropy (or getentropy) before
> you added it, so how could it be picked up?  Not ruling out
> bugs in libstdc++-v3 configuration here.  Maybe it didn't
> recognize your mix as a newlib target?  (It should default
> to it from the target tuple, but you can always add a
> --with-newlib.)

Yes there was (pardon the typo in the previous mail as the header only 
included getentropy and not _getentropy): 
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/unistd.h;h=5386bd49dc4f700180c94b4a6ab56c8196e6f77b;hb=70ee6b17df9b055a05cdcc4d3fe1813d7b57e2d8#l107

That prototype is picked up by the configure script in libstdc++ here: 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/configure;h=bef2b840a595b6ec3a2c24eb3efb04f6835f62b7;hb=refs/heads/master#l51573

As I am cross compiling, it will not try to link and thus, it's 
perfectly legal (from the POV of the C compiler) to have the prototype 
but no implementation and thus, it thinks that getentropy is available 
while it's not.

> If you didn't post your complete configure line and
> config.log in previous reports and conversions to newlib@
> and gcc lists, please do.

I have not, but it's more or less the same flags that are used in the 
official arm-none-eabi build from Arm 
(https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads).

newlib:
.../src/newlib/configure --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=arm-none-eabi 
--prefix=.../install-native 
--infodir=.../install-native/share/doc/gcc-arm-none-eabi/info 
--mandir=.../install-native/share/doc/gcc-arm-none-eabi/man 
--htmldir=.../install-native/share/doc/gcc-arm-none-eabi/html 
--pdfdir=.../install-native/share/doc/gcc-arm-none-eabi/pdf 
--enable-newlib-io-long-long --enable-newlib-io-c99-formats 
--enable-newlib-reent-check-verify --enable-newlib-register-fini 
--enable-newlib-retargetable-locking --disable-newlib-supplied-syscalls 
--disable-nls

GCC:
.../src/gcc/configure --target=arm-none-eabi --prefix=.../install-native 
--libexecdir=.../install-native/lib 
--infodir=.../install-native/share/doc/gcc-arm-none-eabi/info 
--mandir=.../install-native/share/doc/gcc-arm-none-eabi/man 
--htmldir=.../install-native/share/doc/gcc-arm-none-eabi/html 
--pdfdir=.../install-native/share/doc/gcc-arm-none-eabi/pdf 
--enable-languages=c,c++ --enable-plugins --disable-decimal-float 
--disable-libffi --disable-libgomp --disable-libmudflap 
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch 
--disable-nls --disable-shared --disable-threads --disable-tls 
--with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes 
--with-python-dir=share/gcc-arm-none-eabi 
--with-sysroot=.../install-native/arm-none-eabi --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --with-gmp=.../build-native/host-libs/usr 
--with-mpfr=.../build-native/host-libs/usr 
--with-mpc=.../build-native/host-libs/usr 
--with-isl=.../build-native/host-libs/usr 
'--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic 
-lm' --with-multilib-list=rmprofile,aprofile

> 
>> but when linking, there was no such function defined in the
>> newlib provided archives, thus the following error (taken from the
>> commit message of b9e867d088935d9f0bf312e6dbf3e4976850dfd3) was raised
>> during testing of the g++ tool:
>>
>>   
>> /build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/bin/ld:
>> /build/gcc-13-2709-g9ac9fde961f/bin/../lib/gcc/arm-none-eabi/13.0.0/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libstdc++.a(random.o):
>> in function `std::(anonymous namespace)::__libc_getentropy(void*)':
>>       (.text._ZNSt12_GLOBAL__N_117__libc_getentropyEPv+0x8): undefined
>> reference to `getentropy'
> 
> Right; that means it was *wrongly* identified as present at
> configure-time.  The solution is then not to add a stub, but
> to fix the wrong present-identification.

Well, arc4random, that is part of newlib, also assumes that getentropy 
exists.
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/arc4random.c;h=09a134c3b9dabec8ae414223f082e9dfdcaaeb3a;hb=refs/heads/main#l101

This part was added by Sebastian Huber back in 2016: 
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;f=newlib/libc/stdlib/arc4random.c;h=f74cf1350e4633892b6ee6db3664eec38579a709

>> In my case (cross building and cross testing) is that without my patch,
>> the failure happens in the testsuite.
> 
> Odd; I'll re-read that conversion.  The lack of _getentropy
> (and getentropy) before, *should* not have posed any problem.

Well it does. :)
As there are other things in newlib that depend on this symbol, I though 
it was the right move to add the stub for _getentropy (and the wrapping 
getentropy function) as it "completes" the chain for other parts of 
newlib as well as allowing the proper handling in libstdc++.
If you think the correct approach is to rip out getentropy, _getentropy 
and the arc4random stuff from newlib, then I suppose you should supply a 
patch for it.

>> So, in that case, just add the following to the library? It should be
>> enough to make your simulator happy and it can still be overridden when
>> using newlib built for the cris architecture in real applications.
>>
>> int _getentropy(void *buf, size_t buflen)
>> {
>>     errno = ENOSYS;
>>     return -1;
>> }
>>
> 
> That won't fly.  I mentioned that pruning the stub warning
> exposes runtime errors, so that'll lead to *regressions for
> those libstdc++ tests that expect randomness support to
> work, compared to before the _getentropy stub*.  (Before,
> libstdc++ fell back to to another randomness
> implementation.)

No it does not.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/random.cc;h=75989bd33375800d04a5ca5788f99c103c199ea2;hb=refs/heads/master#l468
I interpret this as the program can be compiled to support a certain 
random source and then at runtime, it's verified that said random source 
is available or not.
Do you make a different interpretation?

>> Looking forward to your "proper solution" as this appears to work fine
>> if you just define the low level implementation for your architecture.
> 
> A proper solution is one that matches what's actually
> implemented in newlib and libgloss.
> 
> It worked before the _getentropy stub, it fails afterwards.
> 
> IMHO it's preferable to target off-the-shelf buildable
> toolchain combinations rather than homegrown collections; if
> the latter work, then fine, but if they break what's already
> there, then that collection should be adjusted, not the rest
> of newlib+libgloss.

I see no reason why the set of newlib, libgloss or GCC matters for this.
When doing a cross compile, the header file is all that matters for the 
support to be picked up by libstdc++ configure script. As such, it will 
later fail to link with said library as the implementation is missing.

As I said before, either we need to rip out *everything* that loops back 
to getentropy from newlib or there needs to be something that provides a 
working implementation for your use-case. As you appear to be running 
the cris target on linux, I suggest that you simply wrap it to the 
getentropy call on the host for your simulation.

Keep in mind that I don't really care about what works with a simulator 
or not, what I focus on is if real applications will work or not. My way 
of testing the arm-none-eabi target is as close as I can get to real 
application scenarios as it more or less matches how our customers will 
use the toolchain. This is the important part!
Also, I'm not just testing a particular Cortex-M target, I'm testing all 
of the Cortex-M targets that are available in the STM32 portfolio with 
and without FPU. As I'm verifying that all these combinations are 
correct (according to the dejagnu suite), you see why arm-sim will not 
be enough for me.


Kind regards,
Torbjörn