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

[Hans-Peter Nilsson <hp@axis.com>]

> 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