public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Hans-Peter Nilsson <hp@axis.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno
Date: Wed, 01 Mar 2023 08:32:13 -0500	[thread overview]
Message-ID: <d85ae322723362a9fb78886215ec9eb6095b4c42.camel@redhat.com> (raw)
In-Reply-To: <20230301030123.A0A2B20438@pchp3.se.axis.com>

On Wed, 2023-03-01 at 04:01 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm <dmalcolm@redhat.com>
> > Date: Tue, 28 Feb 2023 21:25:34 -0500
> 
> > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > > From: David Malcolm <dmalcolm@redhat.com>
> > > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> > > 
> > > > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > > > > Ok to commit?
> > > > > -- >8 --
> > > > > Investigating analyzer tesstsuite errors for cris-elf.  The
> > > > > same
> > > > > are
> > > > > seen for pru-elf according to posts to gcc-testresults@.
> > > > > 
> > > > > For glibc, errno is #defined as:
> > > > >  extern int *__errno_location (void) __THROW
> > > > > __attribute_const__;
> > > > >  # define errno (*__errno_location ())
> > > > > while for newlib in its default configuration, it's:
> > > > >  #define errno (*__errno())
> > > > >  extern int *__errno (void);
> > > > 
> > > > We're already handling ___errno (three underscores) for Solaris
> > > > as
> > > > of
> > > > 7c9717fcb5cf94ce1e7ef5c903058adf9980ff28; does it fix the issue
> > > > if
> > > > you 
> > > > add __errno (two underscores) to analyzer/kf.cc's 
> > > > register_known_functions in an analogous way to that commit? 
> > > > (i.e.
> > > > wiring it up to kf_errno_location, "teaching" the analyzer that
> > > > that
> > > > function returns a pointer to the "errno region")
> > > 
> > > But...there's already "support" for two underscores since
> > > the commit you quote, so I guess not.  
> > 
> > Is there?  That commit adds support for:
> >   __error
> > but not for:
> >   __errno
> > unless there's something I'm missing.
> 
> No, it's me.  Apparently I can't spot the difference between
> error and errno.  Sorry.
> 
> It's nice to know that the const-attribute (to signal that
> the pointer points to a constant location) works
> automatically, i.e. the Solaris and glibc definitions should
> not (no longer?) be needed - unless there's other
> errno-analyzing magic elsewhere too.  

With the const-attribute, the analyzer "knows" that the pointer it gets
back always points to the same thing, but it doesn't know what it
points to, and so has to assume that any writes to errno could modify
anything that has escaped.

Also, the analyzer uses region_model::set_errno in various
known_function implementations, e.g. for functions that can succeed or
fail, to set errno on the "failure" execution path to a new symbolic
value that tests as > 0.

> Either way, since
> there's specific support for this errno kind of thing, that
> certainly works for me.  The patch gets smaller too. :)

:)

> 
> So, how's this instead, pending full testing (only
> analyzer.exp spot-tested)?

Looks good, though how about adding a mention of newlib to the comment
immediately above (the one that talks about Solaris and OS X)?

Thanks for fixing this
Dave


  reply	other threads:[~2023-03-01 13:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 18:47 Hans-Peter Nilsson
2023-02-28 19:12 ` David Malcolm
2023-03-01  0:59   ` Hans-Peter Nilsson
2023-03-01  2:25     ` David Malcolm
2023-03-01  3:01       ` Hans-Peter Nilsson
2023-03-01 13:32         ` David Malcolm [this message]
2023-03-01 15:36           ` Hans-Peter Nilsson
2023-03-01 16:02             ` Hans-Peter Nilsson
2023-03-01 23:23               ` Bernhard Reutner-Fischer
2023-03-01 23:54                 ` Hans-Peter Nilsson
2023-03-02  0:37                   ` Bernhard Reutner-Fischer
2023-03-02  0:58                     ` Hans-Peter Nilsson

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=d85ae322723362a9fb78886215ec9eb6095b4c42.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hp@axis.com \
    /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).