On 03/02/2019 20:39, Luc Van Oostenryck wrote: > 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). Yeah, I wouldn't be surprised that quite a few things no longer work correctly as it stands, but my thought was not to make it any worse. ;-) Having said that, nobody seems to be complaining, so ... I will leave the decision to you! :-D ATB, Ramsay Jones
