From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Hans-Peter Nilsson <hp@axis.com>
Cc: <newlib@sourceware.org>
Subject: Re: [committed 0/2] CRIS: Fix compilation warnings that recent gcc treats as errors
Date: Thu, 21 Dec 2023 18:37:14 +0100 [thread overview]
Message-ID: <453f176d-2e02-4b61-956c-b0ff5c2b8023@foss.st.com> (raw)
In-Reply-To: <20231215042450.10C6220430@pchp3.se.axis.com>
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
next prev parent reply other threads:[~2023-12-21 17:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 17:50 Hans-Peter Nilsson
2023-12-06 19:52 ` Torbjorn SVENSSON
2023-12-15 4:24 ` Hans-Peter Nilsson
2023-12-21 17:37 ` Torbjorn SVENSSON [this message]
2023-12-21 18:26 ` Hans-Peter Nilsson
2023-12-23 10:58 ` Torbjorn SVENSSON
2023-12-23 16:44 ` Hans-Peter Nilsson
2023-12-24 10:49 ` Torbjorn SVENSSON
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453f176d-2e02-4b61-956c-b0ff5c2b8023@foss.st.com \
--to=torbjorn.svensson@foss.st.com \
--cc=hp@axis.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).