On Sun, 15 Jun 2014 00:05:22 +1000 Vitaly Osipov <vitaly.osipov@xxxxxxxxx> wrote: > Which GCC? I built sparse on Ubuntu with 4.8 and -fpic - still nothing. This must be Fedora specific somehow. > > > Regards, > > Vitaly > $ gcc --version gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7) Yeah, playing around a little more, it seems like -fpic alone is not enough to trigger it, but CFLAGS='-O2 -fpic' seems to cause it. Can you confirm whether that helps you to reproduce it as well? Also, I'm on x86_64 (in case the arch matters here). > > On 14 Jun 2014, at 11:44 pm, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > > > On Fri, 13 Jun 2014 08:56:50 -0700 > > Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: > > > >>> On Fri, Jun 13, 2014 at 08:05:37AM -0400, Jeff Layton wrote: > >>> On Thu, 12 Jun 2014 18:06:25 +1000 > >>> Vitaly Osipov <vitaly.osipov@xxxxxxxxx> wrote: > >>> > >>>> Nothing shows up for me on x86_64, allmodconfig, linux-next from 10 of > >>>> June. My sparse has been compiled from sources. > >>>> > >>>> $ make fs/locks.o C=2 CHECK="/home/vosipov/bin/sparse" > >>>> CHK include/config/kernel.release > >>>> CHK include/generated/uapi/linux/version.h > >>>> CHK include/generated/utsrelease.h > >>>> CALL scripts/checksyscalls.sh > >>>> CHECK scripts/mod/empty.c > >>>> CHECK fs/locks.c > >>>> > >>>> $ sparse —version > >>>> v0.5.0 > >>>> > >>>> $ which sparse > >>>> /home/vosipov/bin/sparse > >>>> > >>>> Regards, > >>>> Vitaly > >>>> > >>>> > >>>>> On Wed, Jun 11, 2014 at 11:51 PM, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > >>>>> On Wed, 11 Jun 2014 16:11:46 +0300 > >>>>> Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > >>>>> > >>>>>>> On Wed, Jun 11, 2014 at 07:06:32AM -0400, Jeff Layton wrote: > >>>>>>> $ rpm -q sparse > >>>>>>> sparse-0.5.0-1.fc20.x86_64 > >>>>>>> > >>>>>>> I see it all over the tree, but an easy example is fs/locks.c: > >>>>>>> > >>>>>>> $ make fs/locks.o C=1 > >>>>>>> make[1]: Nothing to be done for `all'. > >>>>>>> make[1]: Nothing to be done for `relocs'. > >>>>>>> CHK include/config/kernel.release > >>>>>>> CHK include/generated/uapi/linux/version.h > >>>>>>> CHK include/generated/utsrelease.h > >>>>>>> CALL scripts/checksyscalls.sh > >>>>>>> CHECK fs/locks.c > >>>>>>> include/linux/err.h:35:16: warning: dereference of noderef expression > >>>>>>> include/linux/err.h:30:23: warning: dereference of noderef expression > >>>>>>> include/linux/err.h:35:16: warning: dereference of noderef expression > >>>>>>> include/linux/err.h:30:23: warning: dereference of noderef expression > >>>>>>> CC fs/locks.o > >>>>>>> > >>>>>>> It has two IS_ERR calls and two PTR_ERR calls, and each generates the > >>>>>>> warning. > >>>>>> > >>>>>> I downloaded the Fedora SRPM and built the binary but I still wasn't > >>>>>> able to reproduce the bug. > >>>>>> > >>>>>> dcarpenter@speke:~/progs/kernel/devel$ /tmp/sparse/sparse-0.5.0/sparse --version > >>>>>> 0.5.0 > >>>>>> dcarpenter@speke:~/progs/kernel/devel$ make C=2 CHECK=/tmp/sparse/sparse-0.5.0/sparse fs/locks.o > >>>>>> CHK include/config/kernel.release > >>>>>> CHK include/generated/uapi/linux/version.h > >>>>>> CHK include/generated/utsrelease.h > >>>>>> CALL scripts/checksyscalls.sh > >>>>>> <stdin>:1226:2: warning: #warning syscall finit_module not implemented [-Wcpp] > >>>>>> <stdin>:1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp] > >>>>>> <stdin>:1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp] > >>>>>> <stdin>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp] > >>>>>> CHECK scripts/mod/empty.c > >>>>>> CHECK fs/locks.c > >>>>>> dcarpenter@speke:~/progs/kernel/devel$ > >>>>>> > >>>>>> I'm on today's linux-next. I can't think of a kernel configuration > >>>>>> issue which would cause this... > >>>>>> > >>>>>> regards, > >>>>>> dan carpenter > >>>>> > >>>>> Could it be arch-specific then? What arch are you using? I'm on x86_64. > >>>>> I know that quite a few other people have mentioned seeing these > >>>>> warnings as well, so I'm pretty sure it's not just me. > >>> > >>> Ha! It turns out that my hand-built sparse also works fine, so the > >>> problem seems to be in the Fedora package. > >>> > >>> With a little trial-and-error, I figured out what's causing the > >>> problem, but I'm a little baffled as to why it's occurring. > >>> > >>> The Fedora SRPM builds the program with -fpic. When I remove that flag, > >>> this problem goes away. I'd appreciate any insight into why that would > >>> break things. I doubt PIC really makes much difference security-wise in > >>> sparse, so removing it shouldn't matter much, but I wonder if this > >>> indicates an underlying bug in sparse itself? > >> > >> Wow, that's horrifying. I wonder if it might indicate a miscompilation > >> by GCC. Does the problem persist if you build with -fpic -g? If so, > >> you could set a few breakpoints and try to determine at what point the > >> behavior of the two sparse binaries diverges. > > > > Yeah, this is a bit disturbing. Fedora already builds with -g, so yes, > > the problem does persist. I made a very small, simple C file that just > > calls IS_ERR to test with. > > > > Broken sparse (built with -fpic): > > > > Breakpoint 1, expand_dereference (expr=0x7ffff6f12210) at expand.c:629 > > 629 if (expr->ctype->ctype.modifiers & MOD_NODEREF) > > (gdb) p expr->ctype->ctype.modifiers > > $3 = 0x65686374616d6e75 > > > > Built w/o -fpic at the same breakpoint: > > > > Breakpoint 1, expand_dereference (expr=0x7ffff5e61bd0) at expand.c:629 > > 629 if (expr->ctype->ctype.modifiers & MOD_NODEREF) > > (gdb) p expr->ctype->ctype.modifiers > > $2 = 0x0 > > > > The stack at that point is: > > > > (gdb) bt > > #0 expand_dereference (expr=0x7ffff5e61bd0) at expand.c:629 > > #1 expand_preop (expr=0x7ffff5e61bd0) at expand.c:736 > > #2 expand_expression (expr=expr@entry=0x7ffff5e61bd0) at expand.c:984 > > #3 0x000000000041217a in expand_cast (expr=0x7ffff5e61c50) at expand.c:777 > > #4 expand_expression (expr=expr@entry=0x7ffff5e61c50) at expand.c:992 > > #5 0x00000000004123e2 in expand_compare (expr=0x7ffff5e61cd0) at expand.c:514 > > #6 expand_expression (expr=<optimized out>) at expand.c:978 > > #7 0x00000000004127ba in expand_preop (expr=0x7ffff5e61d10) at expand.c:752 > > #8 expand_expression (expr=<optimized out>) at expand.c:984 > > #9 0x00000000004127ba in expand_preop (expr=0x7ffff5e61d50) at expand.c:752 > > #10 expand_expression (expr=<optimized out>) at expand.c:984 > > #11 0x0000000000412364 in expand_arguments (head=0x7ffff5e39810) at expand.c:767 > > #12 expand_call (expr=0x7ffff5e61b90) at expand.c:832 > > #13 expand_expression (expr=expr@entry=0x7ffff5e61b90) at expand.c:995 > > #14 0x000000000041217a in expand_cast (expr=0x7ffff5e61e10) at expand.c:777 > > #15 expand_expression (expr=<optimized out>) at expand.c:992 > > #16 0x0000000000411c75 in expand_statement (stmt=stmt@entry=0x7ffff5fe3920) at expand.c:1202 > > #17 0x0000000000411e13 in expand_compound (stmt=0x7ffff5fe38d0) at expand.c:1133 > > #18 expand_statement (stmt=stmt@entry=0x7ffff5fe38d0) at expand.c:1164 > > #19 0x00000000004124ec in expand_expression (expr=<optimized out>) at expand.c:1007 > > #20 0x0000000000411dad in expand_statement (stmt=stmt@entry=0x7ffff5fe3880) at expand.c:1161 > > #21 0x0000000000411e13 in expand_compound (stmt=0x7ffff5fe3830) at expand.c:1133 > > #22 expand_statement (stmt=0x7ffff5fe3830) at expand.c:1164 > > #23 0x0000000000411c21 in expand_symbol (sym=sym@entry=0x7ffff5e312d0) at expand.c:1068 > > #24 0x0000000000401675 in check_symbols (list=0x7ffff6a63610) at sparse.c:281 > > #25 0x0000000000401208 in main (argc=<optimized out>, argv=<optimized out>) at sparse.c:300 > > > > ...so something is corrupting the modifiers field at least and maybe > > the whole ctype itself? I don't know the sparse code that well, so I'll > > need to do some more digging to determine the root cause. > > > > -- > > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
