| Message ID | 20190203114044.50297-1-luc.vanoostenryck@gmail.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
| Series | [v2] predefs: add arch-specific predefines | expand |
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@gmail.com> > --- > > 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. ATB, Ramsay Jones
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@gmail.com> > > --- > > > > 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
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@gmail.com> >>> --- >>> >>> 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
On Sun, Feb 03, 2019 at 08:54:34PM +0000, Ramsay Jones wrote: > On 03/02/2019 20:39, Luc Van Oostenryck wrote: > > On Sun, Feb 03, 2019 at 03:38:24PM +0000, Ramsay Jones wrote: > >> 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 I prefer to have all these macros defined once and avoid subtle breakages because some are defined contradictorily. Best regards, -- Luc
On Sun, Feb 03, 2019 at 12:40:44PM +0100, 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@gmail.com> I intended to pick this patch for the Debian package, but it fails to apply on your public master branch. I will upload without a fix for that now to fix building on all architectures before sparse will be autoremoved from unstable. Other than that I think it would be great to list the actually changed/new symbols in the commit log. (E.g. mips got __mips) Best regards Uwe
On Thu, Feb 07, 2019 at 08:11:33PM +0100, Uwe Kleine-König wrote: > On Sun, Feb 03, 2019 at 12:40:44PM +0100, 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@gmail.com> > > I intended to pick this patch for the Debian package, but it fails to > apply on your public master branch. Sorry, this patch was supposed to be applied above the one fixing the MIPS problem but I forgot the specify this. Anyway, I've now mainlined the 4 pending patches. > Other than that I think it would be great to list the actually > changed/new symbols in the commit log. (E.g. mips got __mips) Done. Best regards, -- Luc
Hello Luc, On 2/7/19 10:12 PM, Luc Van Oostenryck wrote: > On Thu, Feb 07, 2019 at 08:11:33PM +0100, Uwe Kleine-König wrote: >> On Sun, Feb 03, 2019 at 12:40:44PM +0100, 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@gmail.com> >> >> I intended to pick this patch for the Debian package, but it fails to >> apply on your public master branch. > > Sorry, this patch was supposed to be applied above the one > fixing the MIPS problem but I forgot the specify this. Ah, I missed that one. (I searched for 60fc33496 in my mailing list archive without a match.) > Anyway, I've now mainlined the 4 pending patches. I just uploaded a new version of sparse to Debian before noticing your mail and resorted to teach cgcc about mips only. Will look at your committed work when the autobuilders processed my upload. Thanks for your prompt reactions to my reports. That makes it really nice to work with you. Best regards Uwe
On Thu, Feb 07, 2019 at 10:21:20PM +0100, Uwe Kleine-König wrote: > On 2/7/19 10:12 PM, Luc Van Oostenryck wrote: > > > Anyway, I've now mainlined the 4 pending patches. > > I just uploaded a new version of sparse to Debian Great. I just saw the buildd logs and everything seems OK now except: *) the sparc64 install failure is really strange. Can it be an ENOSPC? *) the x32 failure is, of course, still there. Unless there is some new problems, I'll push a v0.6.1 in a few days. > Thanks for your prompt reactions to my reports. That makes it really > nice to work with you. Thanks, it's reciprocal. -- Luc
Hello Luc, On Fri, Feb 08, 2019 at 01:06:15PM +0100, Luc Van Oostenryck wrote: > On Thu, Feb 07, 2019 at 10:21:20PM +0100, Uwe Kleine-König wrote: > > On 2/7/19 10:12 PM, Luc Van Oostenryck wrote: > > > > > Anyway, I've now mainlined the 4 pending patches. > > > > I just uploaded a new version of sparse to Debian > Great. > I just saw the buildd logs and everything seems OK now except: > *) the sparc64 install failure is really strange. Can it be an ENOSPC? This is a parallel building issue. The target $(DESTDIR)$(MAN1DIR)/sparse.1 doesn't depend on install-dirs and so /<<PKGBUILDDIR>>/debian/tmp/usr/share/man/man1/ might not be created yet when install for sparse.1 is called. > *) the x32 failure is, of course, still there. Yeah. This is not that fatal as a failure on a release architecture though. > > Thanks for your prompt reactions to my reports. That makes it really > > nice to work with you. > > Thanks, it's reciprocal. :-D Best regards Uwe
On Fri, Feb 08, 2019 at 02:38:42PM +0100, Uwe Kleine-König wrote: > Hello Luc, > > On Fri, Feb 08, 2019 at 01:06:15PM +0100, Luc Van Oostenryck wrote: > > On Thu, Feb 07, 2019 at 10:21:20PM +0100, Uwe Kleine-König wrote: > > > On 2/7/19 10:12 PM, Luc Van Oostenryck wrote: > > > > > > > Anyway, I've now mainlined the 4 pending patches. > > > > > > I just uploaded a new version of sparse to Debian > > Great. > > I just saw the buildd logs and everything seems OK now except: > > *) the sparc64 install failure is really strange. Can it be an ENOSPC? > > This is a parallel building issue. The target > $(DESTDIR)$(MAN1DIR)/sparse.1 doesn't depend on install-dirs and so > /<<PKGBUILDDIR>>/debian/tmp/usr/share/man/man1/ might not be created yet > when install for sparse.1 is called. Gnahh, yes. I always use -'j' to build but never to install ... Patch is sent. Thanks, -- Luc
diff --git a/cgcc b/cgcc index f3909ae89..a99a3a1c3 100755 --- a/cgcc +++ b/cgcc @@ -287,16 +287,16 @@ sub add_specs { " -D'__fastcall=__attribute__((__fastcall__))'" . " -D'__declspec(x)=__attribute__((x))'"; } elsif ($spec eq 'i386') { - return (' -D__i386=1 -D__i386__=1' . + return ( &float_types (1, 1, 21, [24,8], [53,11], [64,15])); } elsif ($spec eq 'sparc') { - return (' -D__sparc=1 -D__sparc__=1' . + return ( &integer_types (8, 16, 32, $m64 ? 64 : 32, 64) . &float_types (1, 1, 33, [24,8], [53,11], [113,15]) . &define_size_t ($m64 ? "long unsigned int" : "unsigned int") . ' -D__SIZEOF_POINTER__=' . ($m64 ? '8' : '4')); } elsif ($spec eq 'sparc64') { - return (' -D__sparc=1 -D__sparc__=1 -D__sparcv9__=1 -D__sparc64__=1 -D__arch64__=1 -D__LP64__=1' . + return ( &integer_types (8, 16, 32, 64, 64, 128) . &float_types (1, 1, 33, [24,8], [53,11], [113,15]) . &define_size_t ("long unsigned int") . @@ -304,25 +304,23 @@ sub add_specs { } elsif ($spec eq 'x86_64') { return &float_types (1, 1, 33, [24,8], [53,11], [113,15]); } elsif ($spec eq 'ppc') { - return (' -D__powerpc__=1 -D_BIG_ENDIAN -D_STRING_ARCH_unaligned=1' . + return (' -D_BIG_ENDIAN -D_STRING_ARCH_unaligned=1' . &integer_types (8, 16, 32, $m64 ? 64 : 32, 64) . &float_types (1, 1, 21, [24,8], [53,11], [113,15]) . &define_size_t ($m64 ? "long unsigned int" : "unsigned int") . ' -D__SIZEOF_POINTER__=' . ($m64 ? '8' : '4')); } elsif ($spec eq 'ppc64') { - return (' -D__powerpc__=1 -D__PPC__=1 -D_STRING_ARCH_unaligned=1' . - ' -D__powerpc64__=1 -D__PPC64__=1' . - ' -m64' . + return (' -D_STRING_ARCH_unaligned=1 -m64' . &float_types (1, 1, 21, [24,8], [53,11], [113,15])); } elsif ($spec eq 's390x') { - return (' -D__s390x__ -D__s390__ -D_BIG_ENDIAN' . + return (' -D_BIG_ENDIAN' . &integer_types (8, 16, 32, $m64 ? 64 : 32, 64) . &float_types (1, 1, 36, [24,8], [53,11], [113,15]) . &define_size_t ("long unsigned int") . ' -D__SIZEOF_POINTER__=' . ($m64 ? '8' : '4')); } elsif ($spec eq 'arm') { chomp (my $gccmachine = `$cc -dumpmachine`); - my $cppsymbols = ' -D__arm__=1 -m32'; + my $cppsymbols = ' -m32'; if ($gccmachine eq 'arm-linux-gnueabihf') { $cppsymbols .= ' -D__ARM_PCS_VFP=1'; @@ -331,7 +329,7 @@ sub add_specs { return ($cppsymbols . &float_types (1, 1, 36, [24,8], [53,11], [53, 11])); } elsif ($spec eq 'aarch64') { - return (' -D__aarch64__=1 -m64' . + return (' -m64' . &float_types (1, 1, 36, [24,8], [53,11], [113,15])); } elsif ($spec eq 'host_os_specs') { my $os = `uname -s`; diff --git a/lib.c b/lib.c index 60fc33496..91d347109 100644 --- a/lib.c +++ b/lib.c @@ -1364,20 +1364,73 @@ static void predefined_macros(void) break; } - if (arch_m64 != ARCH_LP32) { -#if defined(__x86_64__) || defined(__x86_64) - predefine("__x86_64__", 1, "1"); - predefine("__x86_64", 1, "1"); -#endif - } - switch (arch_mach) { + case MACH_ARM64: + predefine("__aarch64__", 1, "1"); + break; + case MACH_ARM: + predefine("__arm__", 1, "1"); + break; + case MACH_M68K: + predefine("__m68k__", 1, "1"); + break; case MACH_MIPS64: + if (arch_m64 == ARCH_LP64) + predefine("__mips64", 1, "64"); + /* fall-through */ case MACH_MIPS32: + predefine("__mips", 1, "%d", ptr_ctype.bit_size); predefine("_MIPS_SZINT", 1, "%d", int_ctype.bit_size); predefine("_MIPS_SZLONG", 1, "%d", long_ctype.bit_size); predefine("_MIPS_SZPTR", 1, "%d", ptr_ctype.bit_size); break; + case MACH_PPC64: + if (arch_m64 == ARCH_LP64) { + predefine("__powerpc64__", 1, "1"); + predefine("__ppc64__", 1, "1"); + predefine("__PPC64__", 1, "1"); + } + /* fall-through */ + case MACH_PPC32: + predefine("__powerpc__", 1, "1"); + predefine("__powerpc", 1, "1"); + predefine("__ppc__", 1, "1"); + predefine("__PPC__", 1, "1"); + break; + case MACH_RISCV64: + case MACH_RISCV32: + predefine("__riscv", 1, "1"); + predefine("__riscv_xlen", 1, "%d", ptr_ctype.bit_size); + break; + case MACH_S390X: + predefine("__zarch__", 1, "1"); + predefine("__s390x__", 1, "1"); + predefine("__s390__", 1, "1"); + break; + case MACH_SPARC64: + if (arch_m64 == ARCH_LP64) { + predefine("__sparc_v9__", 1, "1"); + predefine("__sparcv9__", 1, "1"); + predefine("__sparcv9", 1, "1"); + predefine("__sparc64__", 1, "1"); + predefine("__arch64__", 1, "1"); + } + /* fall-through */ + case MACH_SPARC32: + predefine("__sparc__", 1, "1"); + predefine("__sparc", 1, "1"); + break; + case MACH_X86_64: + if (arch_m64 != ARCH_LP32) { + predefine("__x86_64__", 1, "1"); + predefine("__x86_64", 1, "1"); + break; + } + /* fall-through */ + case MACH_I386: + predefine("__i386__", 1, "1"); + predefine("__i386", 1, "1"); + break; } }
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@gmail.com> --- Change since v1: -) add __PPC__, __PPC64__, __sparsev9__, __sparc64__ & __s390__ which were defined in cgcc but not sparse itself. -) remove redundant defs in cgcc cgcc | 18 +++++++--------- lib.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 68 insertions(+), 17 deletions(-)