linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: josh@joshtriplett.org
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	Christopher Li <sparse@chrisli.org>,
	Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH] sparse/parse.c: ignore hotpatch attribute
Date: Thu, 30 Apr 2015 10:38:23 -0700	[thread overview]
Message-ID: <20150430173823.GA9379@cloud> (raw)
In-Reply-To: <CA+55aFzZtGyz3CLF5Hjyjr0GVkx3SYui8yE9JjO5tzzHZzk78g@mail.gmail.com>

On Thu, Apr 30, 2015 at 08:45:33AM -0700, Linus Torvalds wrote:
> On Tue, Apr 28, 2015 at 3:48 AM, Heiko Carstens
> <heiko.carstens@de.ibm.com> wrote:
> > gcc knows about a new "hotpatch" attribute which sparse can safely ignore,
> > since it modifies only which code will be generated just like the
> > "no_instrument_function" attribute.
> 
> I'm wondering if sparse should just ignore all attributes it doesn't
> recognize, so that we could just remove this ever-expanding list of
> things that don't actually matter for sparse..
> 
> The "unrecognized attribute" thing made more sense way back when -
> when I wanted to get he basic attributes handled. Now it's just
> noise...

Unfortunately, ever so often there's an attribute we *can't* just
ignore, and in those cases it's better for us to warn rather than
breaking.  For instance, we won't just be able to ignore "cleanup"; we
need to actually handle it, because it affects code flow.

I think part of the problem arises because sparse claims (via the
preprocessor symbols we provide) to be whatever version of GCC it was
compiled with.  I think that's a mistake.  We should pick a version of
GCC for which we support all the attributes we actually need to do
something with, and advertise ourselves specifically as that version.
That way, a codebase that includes detection for available GCC features
will avoid feeding us attributes and other features that we don't
understand.

I suspect that 3.2 is probably the version sparse should claim to be,
for now.

We could then use something like the patch you posted, possibly with the
addition of an attribute blacklist for any attributes we know we need to
do something with but don't yet, so that we warn about *those*
attributes and no others.  For anything only supported by a newer
version of GCC, it's the code we're scanning's fault for feeding us
something we never claimed to understand.

We can then update the version of GCC we claim to be once we add support
for any features of that version of GCC that absolutely need Sparse
support.

- Josh Triplett

  parent reply	other threads:[~2015-04-30 17:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 10:48 [PATCH] sparse/parse.c: ignore hotpatch attribute Heiko Carstens
2015-04-29 23:22 ` Christopher Li
2015-04-30 11:47   ` Heiko Carstens
2015-04-30 15:45 ` Linus Torvalds
2015-04-30 15:50   ` Nicholas Mc Guire
2015-04-30 17:38   ` josh [this message]
2015-04-30 17:51     ` Linus Torvalds
2015-04-30 19:41       ` josh

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=20150430173823.GA9379@cloud \
    --to=josh@joshtriplett.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    --cc=torvalds@linux-foundation.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 NNTP newsgroup(s).