public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
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

  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).