Message ID | 20170830161435.krq44m5zub4mq43x@taurus.defre.kleine-koenig.org (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On 30/08/17 17:14, Uwe Kleine-König wrote: > Hello, > > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is > nicely catched by the testsuite, e.g.: The only architecture, from the above list, that is not supported by cgcc seems to be ppc32le. > ukleinek@plummer:~/sparse$ git rev-parse HEAD > 958c11c35d98417eb6b948bffe2dffed14eb3320 > ukleinek@plummer:~/sparse$ uname -a > Linux plummer 4.9.0-3-powerpc64le #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) ppc64le GNU/Linux > ukleinek@plummer:~/sparse$ make check V=1 It would be easier to see the results if you _didn't_ add V=1. ;-) [snip] > Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail) > Makefile:232: recipe for target 'check' failed > make: *** [check] Error 1 > ukleinek@plummer:~/sparse$ The additional five failures are all in the llvm backend (sparsec), which you do not need to use sparse as a 'checker'. > The problem is that some cpp symbols are not defined in sparse that are > expected to exist. So I can "fix" backend/sum.c with the following > patch: > > diff --git a/validation/backend/sum.c b/validation/backend/sum.c > index 0604299..d0be8dd 100644 > --- a/validation/backend/sum.c > +++ b/validation/backend/sum.c > @@ -1,3 +1,5 @@ > +#define __powerpc64__ > +#define _CALL_ELF 2 > #include <stdio.h> > #include <stdlib.h> > > Yep, sparse/sparsec do not define various macros that gcc/clang define by default on a given architecture. This is a known problem (that I have been meaning to fix ...). The 'workaround' for the time being is to use the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps 'cgcc -no-compile'). [You didn't mention your usage - is this for a kernel build?] ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On Wed, Aug 30, 2017 at 05:55:00PM +0100, Ramsay Jones wrote: > On 30/08/17 17:14, Uwe Kleine-König wrote: > > ukleinek@plummer:~/sparse$ make check V=1 > > It would be easier to see the results if you _didn't_ add V=1. ;-) noted for the next time. > [snip] > > Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail) > > Makefile:232: recipe for target 'check' failed > > make: *** [check] Error 1 > > ukleinek@plummer:~/sparse$ > > The additional five failures are all in the llvm backend (sparsec), > which you do not need to use sparse as a 'checker'. > > > The problem is that some cpp symbols are not defined in sparse that are > > expected to exist. So I can "fix" backend/sum.c with the following > > patch: > > > > diff --git a/validation/backend/sum.c b/validation/backend/sum.c > > index 0604299..d0be8dd 100644 > > --- a/validation/backend/sum.c > > +++ b/validation/backend/sum.c > > @@ -1,3 +1,5 @@ > > +#define __powerpc64__ > > +#define _CALL_ELF 2 > > #include <stdio.h> > > #include <stdlib.h> > > > > > > Yep, sparse/sparsec do not define various macros that gcc/clang define > by default on a given architecture. This is a known problem (that I have > been meaning to fix ...). The 'workaround' for the time being is to use > the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps > 'cgcc -no-compile'). > > [You didn't mention your usage - is this for a kernel build?] This problem became visible during the make check phase when creating packaged on the listed archs for horst[1]. You can see a build logs at https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0 https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0 The error message looks identical (I checked the ppc64el log) to the problem with backend/sum.c: sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch] /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h' Makefile:113: recipe for target 'check' failed make[1]: *** [check] Error 1 Best regards Uwe [1] https://packages.debian.org/sid/horst
On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote: >> > >> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c >> > index 0604299..d0be8dd 100644 >> > --- a/validation/backend/sum.c >> > +++ b/validation/backend/sum.c >> > @@ -1,3 +1,5 @@ >> > +#define __powerpc64__ >> > +#define _CALL_ELF 2 >> > #include <stdio.h> >> > #include <stdlib.h> >> > >> > >> >> Yep, sparse/sparsec do not define various macros that gcc/clang define >> by default on a given architecture. This is a known problem (that I have >> been meaning to fix ...). The 'workaround' for the time being is to use >> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps >> 'cgcc -no-compile'). >> >> [You didn't mention your usage - is this for a kernel build?] > > This problem became visible during the make check phase when creating packaged > on the listed archs for horst[1]. You can see a build logs at > > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0 > > The error message looks identical (I checked the ppc64el log) to the > problem with backend/sum.c: > > sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch] > /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h' That is very much like on x86_64 missing define "#weak_define __x86_64__ 1" Does cgcc work for you? In the future we do want to move the archetecture related define from cgcc into sparse by itself. For now you can set "sparse" as "cgcc -no-compile" Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Christopher, On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote: > On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote: > >> > > >> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c > >> > index 0604299..d0be8dd 100644 > >> > --- a/validation/backend/sum.c > >> > +++ b/validation/backend/sum.c > >> > @@ -1,3 +1,5 @@ > >> > +#define __powerpc64__ > >> > +#define _CALL_ELF 2 > >> > #include <stdio.h> > >> > #include <stdlib.h> > >> > > >> > > >> > >> Yep, sparse/sparsec do not define various macros that gcc/clang define > >> by default on a given architecture. This is a known problem (that I have > >> been meaning to fix ...). The 'workaround' for the time being is to use > >> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps > >> 'cgcc -no-compile'). > >> > >> [You didn't mention your usage - is this for a kernel build?] > > > > This problem became visible during the make check phase when creating packaged > > on the listed archs for horst[1]. You can see a build logs at > > > > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0 > > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0 > > > > The error message looks identical (I checked the ppc64el log) to the > > problem with backend/sum.c: > > > > sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch] > > /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h' > > That is very much like on x86_64 missing define "#weak_define __x86_64__ 1" > > Does cgcc work for you? In the future we do want to move the archetecture > related define from cgcc into sparse by itself. For now you can set > "sparse" as "cgcc -no-compile" Yes that works. So to address the Debian bug I can do: - move sparse to /usr/lib - teach cgcc about the move of sparse - make /usr/bin/sparse call cgcc -no-compile "$@" or is it easier to teach sparse about the architecture stuff? Best regards Uwe
On 31/08/17 21:55, Uwe Kleine-König wrote: > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote: >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1" >> >> Does cgcc work for you? In the future we do want to move the archetecture >> related define from cgcc into sparse by itself. For now you can set >> "sparse" as "cgcc -no-compile" > > Yes that works. So to address the Debian bug I can do: > > - move sparse to /usr/lib > - teach cgcc about the move of sparse > - make /usr/bin/sparse call cgcc -no-compile "$@" Hmm, I don't think that would be a good idea ... > or is it easier to teach sparse about the architecture stuff? I now understand (I think!) that you are building a sparse package (presumably a .deb) and you are concerned that sparse does not pass it's own testsuite on those platforms. As I said before, the additional failures you are seeing are in the 'llvm backend' code (which, as far as I know, only passes on x86_64 Linux), and in my opinion the llvm-backend programs should not be installed. (The Makefile will build them automatically if you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk). [I would like to see build variable(s) to allow the user to suppress the build (or installation) of the other 'non-primary' sparse programs.] Anyway, if you were to un-install llvm, sparse-llvm etc., would not be built, and the tests would not be run ... ;-) Christopher, as the project maintainer, has the joy of making these kinds of decisions! :-D ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 31, 2017 at 6:43 PM, Ramsay Jones >> - move sparse to /usr/lib >> - teach cgcc about the move of sparse >> - make /usr/bin/sparse call cgcc -no-compile "$@" > > Hmm, I don't think that would be a good idea ... > Agree. > > Anyway, if you were to un-install llvm, sparse-llvm etc., would not > be built, and the tests would not be run ... ;-) I think Uwe already confirm using cgcc to invoke sparse will fix the problem. In this test, we just need to use cgcc to invoke sparse-llvm. I have a patch to fix the usage in test-suite in the other email. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On 08/30/2017 06:14 PM, Uwe Kleine-König wrote: > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is > nicely catched by the testsuite, e.g.: > > [..] Just a heads up: I uploaded 0.5.2 to Debian and there are problems left on hurd-i386 (where PATH_MAX isn't defined[1]) and x32 where I get: env CHECK=./sparse ./cgcc -no-compile memops.c /usr/include/x86_64-linux-gnux32/gnu/stubs.h:10:12: error: unable to open 'gnu/stubs-64.h' The stubs.h file looks as follows: #if !defined __x86_64__ # include <gnu/stubs-32.h> #endif #if defined __x86_64__ && defined __LP64__ # include <gnu/stubs-64.h> #endif #if defined __x86_64__ && defined __ILP32__ # include <gnu/stubs-x32.h> #endif Given that libc6-dev only provides stubs-x32.h from these three, I guess we must not define __LP64__ in this case. I don't have a x32 machine handy, but the complete build log of the auto builder can be found at https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=x32&ver=0.5.2-1&stamp=1524169455&raw=0 Best regards Uwe [1] https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0
On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote: > Hello, > > On 08/30/2017 06:14 PM, Uwe Kleine-König wrote: > > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so > > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is > > nicely catched by the testsuite, e.g.: > > > > [..] > > Just a heads up: I uploaded 0.5.2 to Debian and there are problems left > on hurd-i386 (where PATH_MAX isn't defined[1]) > ... > [1] > https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0 Thanks for the repport. I'll see what can be done. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/27/2018 09:33 AM, Luc Van Oostenryck wrote: > On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote: >> Hello, >> >> On 08/30/2017 06:14 PM, Uwe Kleine-König wrote: >>> Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so >>> common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is >>> nicely catched by the testsuite, e.g.: >>> >>> [..] >> >> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left >> on hurd-i386 (where PATH_MAX isn't defined[1]) >> ... >> [1] >> https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0 > > Thanks for the repport. > I'll see what can be done. I think the default idiom is: #ifndef PATH_MAX #define PATH_MAX 4096 #endif Best regards Uwe
On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote: > Hello, > > On 08/30/2017 06:14 PM, Uwe Kleine-König wrote: > > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so > > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is > > nicely catched by the testsuite, e.g.: > > > > [..] > > Just a heads up: I uploaded 0.5.2 to Debian and there are problems left > ... > and x32 where I get: > > env CHECK=./sparse ./cgcc -no-compile memops.c > /usr/include/x86_64-linux-gnux32/gnu/stubs.h:10:12: error: unable to > open 'gnu/stubs-64.h' > > The stubs.h file looks as follows: > > #if !defined __x86_64__ > # include <gnu/stubs-32.h> > #endif > #if defined __x86_64__ && defined __LP64__ > # include <gnu/stubs-64.h> > #endif > #if defined __x86_64__ && defined __ILP32__ > # include <gnu/stubs-x32.h> > #endif > > Given that libc6-dev only provides stubs-x32.h from these three, I guess > we must not define __LP64__ in this case. Mmmm, yes, surely. For the moment sparse use __LP64__ unconditionnaly for __x86_64__. > I don't have a x32 machine But can you launch a test build for sparse easily enough? I guess that there is no install CD available yet? -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2018 at 09:48:31AM +0200, Uwe Kleine-König wrote: > Hello Luc, > > On 04/27/2018 09:43 AM, Luc Van Oostenryck wrote: > >> I don't have a x32 machine > > > > But can you launch a test build for sparse easily enough? > > Hmm, well, I can upload a new version of sparse and then it will be > build on all archs and then made available for all unstable users. So I > don't want to schedule builds to debug x32 builds. Yes, it's understandable. > > I guess that there is no install CD available yet? > > I think it's not too hard to setup a x32 chroot on amd64. > > See https://wiki.debian.org/X32Port . I'll see what's the easiest for me. The main issue in sparse itself is very trivial but some changes are also needed for cgcc and this will need more tests. Best regards, -- luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 27, 2018 at 09:33:55AM +0200, Uwe Kleine-König wrote: > On 04/27/2018 09:33 AM, Luc Van Oostenryck wrote: > > On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote: > >> Hello, > >> > >>> [..] > >> > >> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left > >> on hurd-i386 (where PATH_MAX isn't defined[1]) > >> ... > >> [1] > >> https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0 > > > > Thanks for the repport. > > I'll see what can be done. > > I think the default idiom is: > > #ifndef PATH_MAX > #define PATH_MAX 4096 > #endif Yes. I had hoped to avoid this together with removing a memcpy() but things are more annoying than I had first thought. Best regards, -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/validation/backend/sum.c b/validation/backend/sum.c index 0604299..d0be8dd 100644 --- a/validation/backend/sum.c +++ b/validation/backend/sum.c @@ -1,3 +1,5 @@ +#define __powerpc64__ +#define _CALL_ELF 2 #include <stdio.h> #include <stdlib.h>