From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-sparse@vger.kernel.org
Subject: Re: [PATCH] arm64: pass machine size to sparse
Date: Tue, 20 Jun 2017 21:07:40 +0200 [thread overview]
Message-ID: <20170620190739.ijtpo3ekibxi47qj@ltop.local> (raw)
In-Reply-To: <20170620170401.GA28035@arm.com>
On Tue, Jun 20, 2017 at 06:04:01PM +0100, Will Deacon wrote:
> On Tue, Jun 20, 2017 at 06:24:32PM +0200, Luc Van Oostenryck wrote:
> > On Tue, Jun 20, 2017 at 04:49:39PM +0100, Will Deacon wrote:
> > > Looks fine to me, but just wondering whether or not we should also be
> > > passing something to indicate the endianness of the target. Does sparse care
> > > about that?
> >
> > Yes, we should. sparse doesn't care per-se but some macros, structures
> > or whole portion of code may depends on '__{LITTLE,BIG}_ENDIAN__'
> > being defined or not, for example (but I don't think it will make
> > a big difference, at least nothing like the 629904 'constant is so big'
> > warnings we have now due to the missing -m64).
> >
> > For this, you have two possibilities:
> > 1) just doing something like PPC:
> > +ifdef CONFIG_CPU_BIG_ENDIAN
> > +CHECKFLAGS += -D__BIG_ENDIAN__
> > +else
> > +CHECKFLAGS += -D__LITTLE_ENDIAN__
> > +endif
> > This will work now. I can't send you a proper patch if you wish.
> >
> > 2) a cleaner solution, IMO, would be to teach sparse about
> > -mlittle-endian/-mbig-endian. In fact I already wrote the patch
> > earlier today. But of course, you will need to wait for the patch
> > to reach sparse's master and then compile sparse yourself or wait
> > for a new release (which shouldn't take much long, though).
>
> If you do that, you could also teach it that AArch64 is 64-bit ;)
Well, currently sparse is arch agnostic and I think it's a good thing.
For the few arch specifities you have to use some of the '-m' flags
(like -m32/-m64, -msize-long). So, for the moment the '-m64' flag
is needed, thus the patch.
-- Luc
WARNING: multiple messages have this Message-ID (diff)
From: luc.vanoostenryck@gmail.com (Luc Van Oostenryck)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: pass machine size to sparse
Date: Tue, 20 Jun 2017 21:07:40 +0200 [thread overview]
Message-ID: <20170620190739.ijtpo3ekibxi47qj@ltop.local> (raw)
In-Reply-To: <20170620170401.GA28035@arm.com>
On Tue, Jun 20, 2017 at 06:04:01PM +0100, Will Deacon wrote:
> On Tue, Jun 20, 2017 at 06:24:32PM +0200, Luc Van Oostenryck wrote:
> > On Tue, Jun 20, 2017 at 04:49:39PM +0100, Will Deacon wrote:
> > > Looks fine to me, but just wondering whether or not we should also be
> > > passing something to indicate the endianness of the target. Does sparse care
> > > about that?
> >
> > Yes, we should. sparse doesn't care per-se but some macros, structures
> > or whole portion of code may depends on '__{LITTLE,BIG}_ENDIAN__'
> > being defined or not, for example (but I don't think it will make
> > a big difference, at least nothing like the 629904 'constant is so big'
> > warnings we have now due to the missing -m64).
> >
> > For this, you have two possibilities:
> > 1) just doing something like PPC:
> > +ifdef CONFIG_CPU_BIG_ENDIAN
> > +CHECKFLAGS += -D__BIG_ENDIAN__
> > +else
> > +CHECKFLAGS += -D__LITTLE_ENDIAN__
> > +endif
> > This will work now. I can't send you a proper patch if you wish.
> >
> > 2) a cleaner solution, IMO, would be to teach sparse about
> > -mlittle-endian/-mbig-endian. In fact I already wrote the patch
> > earlier today. But of course, you will need to wait for the patch
> > to reach sparse's master and then compile sparse yourself or wait
> > for a new release (which shouldn't take much long, though).
>
> If you do that, you could also teach it that AArch64 is 64-bit ;)
Well, currently sparse is arch agnostic and I think it's a good thing.
For the few arch specifities you have to use some of the '-m' flags
(like -m32/-m64, -msize-long). So, for the moment the '-m64' flag
is needed, thus the patch.
-- Luc
next prev parent reply other threads:[~2017-06-20 19:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 12:24 [PATCH] arm64: pass machine size to sparse Luc Van Oostenryck
2017-06-20 15:49 ` Will Deacon
2017-06-20 16:24 ` Luc Van Oostenryck
2017-06-20 16:24 ` Luc Van Oostenryck
2017-06-20 17:04 ` Will Deacon
2017-06-20 17:04 ` Will Deacon
2017-06-20 19:07 ` Luc Van Oostenryck [this message]
2017-06-20 19:07 ` Luc Van Oostenryck
2017-06-21 16:12 ` Will Deacon
2017-06-21 16:12 ` Will Deacon
2017-06-21 16:54 ` Luc Van Oostenryck
2017-06-21 16:54 ` Luc Van Oostenryck
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=20170620190739.ijtpo3ekibxi47qj@ltop.local \
--to=luc.vanoostenryck@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sparse@vger.kernel.org \
--cc=will.deacon@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.