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

On 2023-12-21 19:26, Hans-Peter Nilsson wrote:
>> Date: Thu, 21 Dec 2023 18:37:14 +0100
>> From: Torbjorn SVENSSON <[email protected]>
> 
>> 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 <[email protected]>
>>>> 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