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 12:41:34 -0700	[thread overview]
Message-ID: <20150430194134.GC9971@cloud> (raw)
In-Reply-To: <CA+55aFxCTx32CPkHCJM1NNv67vKHo-6yuTiLOg2Ya-=pn=O36g@mail.gmail.com>

On Thu, Apr 30, 2015 at 10:51:42AM -0700, Linus Torvalds wrote:
> On Thu, Apr 30, 2015 at 10:38 AM,  <josh@joshtriplett.org> wrote:
> > 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.
> 
> Fair enough. Although there may then be headers that are unhappy.

If you mean the GCC internal headers, I don't think those have version
checks; after all, you'd only use them with the GCC they ship with,
right? ;)

For any other headers, I think we'll get worse results by claiming to be
a version of GCC that has features we don't actually support.

> > I suspect that 3.2 is probably the version sparse should claim to be,
> > for now.
> 
> That may be too old. You can't reliably compile the kernel with gcc
> that old (some config options will complain).
> 
> At least CONFIG_GCOV_KERNEL wants 3.4 minimum.

If we want to claim to be 3.4 instead, then there are some attributes
we'll need to check for and warn if we find.  From a quick read of
https://ohse.de/uwe/articles/gcc-attributes.html I think this is a
complete list of attributes in 3.4 that sparse has to care about but
doesn't currently support:

cleanup
gcc_struct
ms_struct

"cleanup" we'll need to handle because it affects control flow;
gcc_struct and ms_struct affect structure layout, which we have warnings
related to.

For the moment, we could just add an explicit warning if we see any of
those three attributes, set our GCC version to 3.4, and then drop the
"unknown attribute" warning.

- Josh Triplett

      reply	other threads:[~2015-04-30 19:41 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
2015-04-30 17:51     ` Linus Torvalds
2015-04-30 19:41       ` josh [this message]

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=20150430194134.GC9971@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).