Re: [PATCH v2] predefs: add arch-specific predefines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 03, 2019 at 03:38:24PM +0000, Ramsay Jones wrote:
> 
> 
> On 03/02/2019 11:40, Luc Van Oostenryck wrote:
> > Predefined macros like '__x86_64__', '__arm__', ... are used
> > in systems headers (and surely at other places too).
> > 
> > So, add them for all archs known to sparse (and remove
> > the corresponding parts in cgcc, they are now redundant).
> > 
> > Note: these  are only tested on i386, x86-64, arm, arm64,
> >       mips64 (ABI O32), ppc, ppc64 (power7), ppc64el (power8)
> >       and sparc64, most of then on a not-so-new OS version.
> > 
> > Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
> > ---
> > 
> > Change since v1:
> > -) add __PPC__, __PPC64__, __sparsev9__, __sparc64__ & __s390__
> >    which were defined in cgcc but not sparse itself.
> > -) remove redundant defs in cgcc
> 
> Hmm, this isn't quite what I had in mind! ;-)
> 
> I had meant to mention this some time ago when previous changes
> also "removed redundant defs" from the 'specs' in cgcc.
> 
> It is possible to specify the '-target=<spec>' to use on the cgcc
> command-line, presumably to allow some 'cross-compilation' ability.
> How effective this would be I don't really know. I have never used
> this facility, but it was presumably added for a reason. (Actually,
> the commits that add the 'specs' don't provide any motivation in
> their commit messages! see eg. commits 14db8c95, and cf2bde63).
> 
> So, this may be going in the wrong direction.

Yes, true. I admit that I've also never used this facility but there
is a number of things that can't possibly work correctly (For example,
if build on x86-64, __x86_64__ will always be defined, independently
of the target and this since a long time already). More recently,
predefines for INT32_TYPE & friends will be wrong too).

To make cross-compiling/'-target=<...>' work in cgcc, sparse needs to
have the same facility itself (and now, thanks to what you and me have
put in place for INT32_TYPE, much of what is needed is there but it's
not in my short-term priorities to add support for this).

-- Luc



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux