Powered by Linux
Re: [BUG] segfault when analysing powerpc kernel code — Semantic Matching Tool

Re: [BUG] segfault when analysing powerpc kernel code

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

 



On Wed, Apr 27, 2016 at 11:32:49AM +1000, Andrew Donnellan wrote:
> On 27/04/16 04:41, Dan Carpenter wrote:
> >On Tue, Apr 26, 2016 at 01:58:11PM +1000, Andrew Donnellan wrote:
> >>Hit the following when attempting to build and check linux-next
> >>20160422 with ARCH=powerpc, pseries_le_defconfig, x86->ppc64le gcc
> >>4.8.3 crosscompiler. The dubious warnings are interesting, but I'm
> >>mostly concerned with the segfault at the end.
> >>
> >>This was with smatch master, but occurs with 1.60 as well.
> >>
> >>Unfortunately I don't have much time to look into this, but let me
> >>know if there's anything else I can provide.
> >>
> >>Please Cc on replies.
> >
> >These warnings are like compile errors from Sparse.  They actually
> >happen before Smatch gets to the code...  Likely an include file isn't
> >getting included or something.
> 
> Yes, I'm aware that the warnings are a sparse problem. Looks like
> sparse has issues with the -maltivec option. For now we're going to
> stub out the vec_xor operation instead
> (http://patchwork.ozlabs.org/patch/614955/) though it really should
> be fixed in sparse, which I might look at when I get the chance. The
> ensuing segfault, otoh, occurs in smatch (see the valgrind log in
> the last email).

True.  But it's not like we were going to get any valid output from
Smatch anyway...

I believe that in  vanilla Sparse it aborts at the first error message.
I hacked it to not do that because some of the error messages happen for
minor things.

My options were:
1) Abort on error and miss real bugs.
2) Do a lot of work to prevent segfaults for unparsable code.
3) Just segfault.

I went with option 3.

It's slightly worse than that actually because I want unlinearized stuff
from Sparse and it mostly gives me that except for when it deals with
sizeof() and inside intializers.  So Smatch tries to linearize it twice
and that gives some errors.  I've looked at trying to fix it but I
couldn't figure it out.  I also reported it but the response was that I
should just linearize it all instead...

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux