gmane.comp.parsers.sparse

Re: unable to open limits.h

Alexey Zaytsev — 2008-11-25T13:04:50

Yes, the commit is located in the gsoc2008-up branch, but you've probably already found it by the time. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: unable to open limits.h

Alexey Zaytsev — 2008-11-25T13:03:24

I see no magic way to find the right path, except specifying which gcc version sparse would have to follow. Probably cgcc could pass it to sparse, but anyway, this would probably be an other patch. Mine does not change the way sparse works, only adds the new include dir, which should not harm the The branch contains cleanups and other straight-forward changes gained as as a side-effect of my sparse linker work this summer. Josh has already agreed on the patches, but was too busy and pobably forgot to pull. Anyway, there is the shortlog: Alexey Zaytsev (9): Make show_symbol newline-consistent Looks more evident this way. Handle a terminal -o option properly. Mark handle_switch as static and don't export it from lib.h Handle missing argument to -D. Gdb macros to get a better look at some sparse data structures. A slightly edited irc discussion with Josh Triplett. Add $GCC_BASE/include-fixed to the include list. Warning should be enough for an unhandled t

Re: unable to open limits.h

Sam Ravnborg — 2008-11-25T12:27:32

Is this the right fix? We should not rely on that sparse is built with the same gcc as currently installed. The fix should be that we automagically uses the right path which is available on the system. For a pull request itis prefarable that you always include: - diffstat - shortlog - short intor what is contained I assume patches has been on sparse ml. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: unable to open limits.h

Christoph Hellwig — 2008-11-25T12:37:43

Oh, looks like your have the change in some bloody branch. Care to send a patch or publish a proper repository? -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: unable to open limits.h

Christoph Hellwig — 2008-11-25T12:36:22

I still see the error with a sparse built from your repository. -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: unable to open limits.h

Alexey Zaytsev — 2008-11-25T12:18:58

This is probably fixed by http://git.zaytsev.su/git?p=sparse.git;a=commitdiff;h=6f089b22a222dd086d14c985c5a67f8b3afd2177 Josh, please pull the gsoc2008-up branch from git://zaytsev.su/git/sparse.git -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

unable to open limits.h

Christoph Hellwig — 2008-11-25T11:07:03

On Ubuntu 8.10 (glibc 2.8.90) I get the following warnings when compiling any program using limits.h: /usr/include/limits.h:125:17: error: unable to open 'limits.h' The easiest testcase is: cat > test.c << EOF #include EOF cgcc -c test.c -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: contextual attributes

Johannes Berg — 2008-11-17T22:10:28

In theory yes, but only half my patches got merged so no. If you search the list you'll find a set of patches from myself that allow you to do this, see below. I have asked that those patches that got merged are reverted for the time being until we can work on a decent implementation, but that hasn't happen either so the current sparse git tree is fairly broken wrt. context attributes... You'd have to annotate startpoint() with __attribute__((context(irqsoff,1,1))) and spin_lock_irq() with __attribute__((context(irqsoff,0,1))) and 1,0 for unlock, in addition to the regular locks. [or something like that, the syntax isn't firm in my mind right now] johannes -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

contextual attributes

Yoann Padioleau — 2008-11-17T21:47:28

Hi, Is it possible by using the __attribute((context(x,y)) sparse attribute to enforce statically that all the callers of certain functions do certain actions such as disabling interrupts ? I would like an attribute like __assume_disabled_interrupt and have such programs: int __assume_disabled_interrupt startpoint() { return 1; } int f1ok() { spin_lock_irq(); startpoint(); spin_unlock_irq(); } int f1bad() { startpoint(); } -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: inline declaration and assignment

Dan Carpenter — 2008-11-15T12:20:27

The thing is that smatch is pretty much abandon-ware until Christmas because I'm cycling through Africa and don't have a computer to work with... :/ On Tue, Nov 11, 2008 at 9:24 AM, Matt use.net> wrote: I really wanted to polish smatch up and make it presentable before I left but I ran out of time. The message isn't an error message. It's means that "ident" could either be null or non-null depending on the if statement. If add_expression() dereferenced the parameter without checking then a message gets printed out there too. There was supposed to be a script that made a list of all the functions that were called with undefined parameters and a list of all the functions that don't check. If a parameter shows up on both lists then it's possibly a bug. cat out.txt | grep "undefined param" | cut -d ' ' -f 5- | sort -u > undefined cat out.txt | grep unchecked | cut -d ' ' -f 5- | sort -u > unchecked cat undefined unchecked | sort | uniq -c As far as declarations go, in sparse the declaration expre

Re: Hard-coded gcc header path

Bernd Petrovitsch — 2008-11-11T23:10:17

[...] I don't think that shipping a copy of .h files from one gcc version will seriously help people using `pcc` (or any other compiler). But I'm probably missing something here. And there probably are similar ones for `pcc` or others. Bernd

Re: Hard-coded gcc header path

Jörn Engel — 2008-11-11T22:32:15

That doesn't strike me as an improvement. I have a workaround, which is to create a symlink in /usr/lib/gcc/i486-linux-gnu/ that matches what sparse expects. If I had to set GCC_INTERNAL_INCLUDE on every invocation, I'd consider that worse than my current workaround. Either sparse gets smart enough to find the headers [1] or it ships its own set. Anything else will continue to fail on one machine or another. [1] Bernd Petrovitsch sent me this neat one-liner in a private mail: gcc -v -E - &1 >/dev/null | sed -n -e '/^#include <\.\.\.> search starts here:/,/^End of search list\./s/^ $.*$/\1/p We could add that to cgcc to set additional include paths. Jörn

Re: Hard-coded gcc header path

Morten Welinder — 2008-11-11T21:00:21

The problem is not the header files, but that we need to ensure that the proper include path is set up. This is needed because sparse currently tries to mimic some indeterminate gcc version in terms of predefines. A similar solution would be needed to mimic any other compiler. We obviously need a default path for system headers somehow. In this case, we could probably get away with accepting a definition of GCC_INTERNAL_INCLUDE on the command line and use that in preference over whatever is in pre-process.h Morten -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Hard-coded gcc header path

Jörn Engel — 2008-11-11T20:28:49

Maybe not even that. It is conceivable to want sparse on systems that don't even have gcc installed. The BSDs seem to favor pcc lately. So the preferred long-term solution would be for sparse to ship its own headers. Jörn

Re: Hard-coded gcc header path

Bernd Petrovitsch — 2008-11-11T14:41:39

[...] There is `gcc -dumpversion`. But it doesn't help if your compiler is from e.g. /opt/gcc-4.1.2 (where mine usually are). And `which`, `type -all`, and similar also doesn't really help as the reported pathname can be actually the ccache binary .... So you want to use the output of ---- snip ---- gcc -v -E - &1 >/dev/null | sed -n -e '/^#include <\.\.\.> search starts here:/,/^End of search list\./s/^ $.*$/\1/p' ---- snip ---- which also seems to work with non-standard paths (like /opt) and ccache in between. Bernd PS: The core of the above line is from http://sourceware.org/ml/crossgcc/2006-12/msg00038.html. The quite trivial `sed` filter is by me.

Re: Hard-coded gcc header path

Jörn Engel — 2008-11-11T14:15:29

Then the short-term solution for debian is clear. Simply rebuild the package and add a dependency on a specific gcc version. Jörn

Re: Hard-coded gcc header path

Johannes Berg — 2008-11-11T14:01:46

Well, sort of. The patch is actually determined at sparse build time, so right now sparse requires you to build it against the same compiler that you are currently using. If you rebuild sparse with your shiny new compiler you'll notice that it'll end up with a different path in pre-process.h. johannes

Hard-coded gcc header path

Jörn Engel — 2008-11-11T13:58:17

Sparse doesn't work for me when compiling userspace code. Others have experienced the same, so I refer to someone else's description of the symptom: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505177 On my system, sparse tries several headers in order, neither of which exists: open("/usr/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory) Not a big surprise when looking at the headers that do exist: Galway:/usr/lib/gcc/i486-linux-gnu# ll total 20 drwxr-xr-x 4 root root 4096 2008-07-01 08:42 3.4.6 drwxr-xr-x 4 root root 4096 2007-09-23 17:59 4.0.4 drwxr-xr-x 3 root root 4096 2008-06-26 00:20 4.1 lrwxrwxrwx 1 root root 3 2007-09-23 20:57 4.1.3 -> 4.1 drwxr-xr-x 3 root root 4096 2008-07-13 11:06 4.2 lrwxrwxrwx 1 root root 3 2008-07-01 08:42 4.2.4 -> 4.2 drwxr-xr-x 4 root root 4096 2008-09-

inline declaration and assignment

Matt — 2008-11-11T06:24:00

Hi, I'm playing with smatch and noticed that an inline assignment doesn't seem to get parsed as such. There's a couple of examples, but this one in sparse's own parse.c (line 1480) is probably the best: struct ident *ident = NULL; sparse doesn't seem to identify this as an assignment, only a declaration. as a result, smatch gives this false positive: parse.c +1487 undefined param add_expression 1 Sorry if I'm incorrectly diagnosing the problem; I'm just diving into the code for the first time this evening :) Thanks in advance for any help! -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OpenBSD support

Christopher Li — 2008-11-04T20:08:12

Acked-by: Christopher Li chrisli.org> On Sun, Nov 2, 2008 at 12:33 AM, Blue Swirl gmail.com> wrote: -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] Sparc64 (Sparc V9, LP64) support

Blue Swirl — 2008-11-02T08:37:12

Hi, This patch adds support for Sparc64 (Sparc V9, LP64). I'm not subscribed, please CC. Signed-off-by: Blue Swirl gmail.com>