http://blog.gmane.org/gmane.comp.parsers.sparse hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.parsers.sparse/1542 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 <limits.h> 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 Christoph Hellwig 2008-11-25T11:07:03 http://comments.gmane.org/gmane.comp.parsers.sparse/1540 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 Yoann Padioleau 2008-11-17T21:47:28 http://comments.gmane.org/gmane.comp.parsers.sparse/1530 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-30 16:27 4.3 lrwxrwxrwx 1 root root 3 2008-07-01 08:42 4.3.1 -> 4.3 lrwxrwxrwx 1 root root 3 2008-08-08 18:18 4.3.2 -> 4.3 So why does sparse try 4.1.2 and not 4.1.3 or 4.3.2 or any other variant? joern< at >Galway:/usr/src/kernel/sparse$ cat pre-process.h #define GCC_INTERNAL_INCLUDE "/usr/lib/gcc/i486-linux-gnu/4.1.2/include" Ah, it is hard-coding the path. So what is the right solution to this problem? Call "gcc --version" and parse the (deliberately hard) output? Or make a copy of the gcc headers and ship them as /usr/lib/sparse/0.4.1/...? Jörn Jörn Engel 2008-11-11T13:58:17 http://comments.gmane.org/gmane.comp.parsers.sparse/1529 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 Matt 2008-11-11T06:24:00 http://comments.gmane.org/gmane.comp.parsers.sparse/1527 Hi, This patch adds support for Sparc64 (Sparc V9, LP64). I'm not subscribed, please CC. Signed-off-by: Blue Swirl <blauwirbel< at >gmail.com> Blue Swirl 2008-11-02T08:37:12 http://comments.gmane.org/gmane.comp.parsers.sparse/1526 Hi, This patch adds OpenBSD support to sparse. I'm not subscribed, please CC. Signed-off-by: Blue Swirl <blauwirbel< at >gmail.com> Blue Swirl 2008-11-02T08:33:23 http://comments.gmane.org/gmane.comp.parsers.sparse/1525 I've just been trying sparse 0.4.1 with linux-next and have noticed that the discussions and patches wrt to the __cold__ attribute have not yet made it into a release version. Would it be possible to put a release of sparse up which handled this attribute please? Ben Dooks 2008-09-14T14:31:52 http://comments.gmane.org/gmane.comp.parsers.sparse/1513 test-unssa.c compiles this: extern void func(int i, ...); void foo(int i) { func(0, (float) i, (double) i, i); } ...into this: fpcast.64 %r3 <- (32) %arg1 scast.64 %r5 <- (32) %arg1 call func, $0, %r3, %r5, %arg1 ret That's with the default settings. Unfortunately, with Clue, sizeof(double) == sizeof(int), so that second instruction comes out as: scast.32 %r5 <- (32) %arg1 This then causes the simplification code in simplify_cast() to discard it: if (size == orig_size) { int op = (orig_type->ctype.modifiers & MOD_SIGNED) ? OP_SCAST : OP_CAST; if (insn->opcode == op) goto simplify; } The end result is that my call statement turns into: call func, $0, %r3, %arg1, %arg1 ...which is wrong. I assume that Clue's odd configuration is violating some assumption somewhere, but I'm not well-enough versed with the sparse internals to know where. It does seem odd to me that it's generating an OP_SCAST to convert the int to a double, rather than an OP_FPCAST like in the float. In the mean time, I've commented out the quoted stanza from simplify_cast() on my setup, which makes things work, but that's not really very pleasant. Can anyone shed light on what might be happening here? Could this be a symptom of some more serious underlying bug? David Given 2008-09-06T21:14:36 http://comments.gmane.org/gmane.comp.parsers.sparse/1512 I notice that struct symbol::arg_count doesn't appear to be used, anywhere. Is this obsolete? David Given 2008-09-06T16:01:50 http://comments.gmane.org/gmane.comp.parsers.sparse/1501 To test the writer: $ ./test-write linearize.c export syms 29 internal 72 import 47 struct instruction * size 349524 struct entrypoint * size 2280 struct basic_block * size 39248 pseudo_t size 118632 struct pseudo_user * size 0 struct asm_constraint * size 0 struct symbol * size 358608 struct asm_rules * size 0 struct multijmp * size 1344 struct expression * size 4064 struct ident * size 12596 struct string * size 0 char * size 0 char * (stream) size 191 struct ptr_list * size 114948 toalsize 995359 It generate linearize.b file. Some internal detail: traverse.c is responsible for traverse the pointer in an object. It don't actually convert the pointer. It delegates the actual convertion to the caller. The reader and writer can share the same traverse code to convert the pointer to index, index back to pointer. The writer use a two pass stage to write the object file. The first pass is finding out which object need to write out to the file. It register them into the hash table for later look up. It add a shadow copy of the object with all the pointer inside the object converted into index. This is a recursive process until all the object under dependency has been registered. The second stage is the actual dumping of the registered file. Compare to the one step convert and dump approach (been there done that). The two step write back generate very nice sequential disk IO. It is also much easier to work with. We can optionally apply some compression method before we write it to the disk. It can save the object file size. Currently it is the raw C structure. Known limits: - static string is not saved yet. The linearizer skip the initialization part of the storage type symbol. We should consider generate some initialization node for lay out the static C structure initializer. - I think the linearized instruction does not have the full C type information yet. - A few more I can't remember right now. - Reader is half baked. Not included in this patch series. Too ugly to show on the list. Drop me a line and I can send you what I got. I will be very glad if some one want to adopt this... Comments are welcome. Chris Signed-Off-By: Christopher Li <sparse< at >chrisli.org> Christopher Li 2008-09-04T05:34:39 http://comments.gmane.org/gmane.comp.parsers.sparse/1500 Signed-Off-By: Christopher Li <sparse< at >chrisli.org> Christopher Li 2008-09-04T05:34:29 http://comments.gmane.org/gmane.comp.parsers.sparse/1499 Hi, I have been hacking on the sparse code dumper for a while. Recently there seems some interested in this, so I resurrect my patches. The dumper works on the native C structure. It convert the pointer inside the struct into index numbers. Hopefully on loading, the same pointer traverse can convert the index back to object pointer. Currently there is no attempt to compress the C structure it writes. So the result is huge, about 50x compare to the stripped .o file on i386. But it give a very good idea how much memory. It needs to load such an object file though. the reader is not ready yet. Chris -- 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 Christopher Li 2008-09-04T05:34:21 http://comments.gmane.org/gmane.comp.parsers.sparse/1488 Hello. I've been working on a "sparse linker" this summer as my Google Summer of Code project. Wasn't neraly as productive as I hoped, but I've got some results that I would like to share. Moreover, I plan continuing this work, and would like to hear comments on what was done so far. The design didn't change much from what was proposed. We run sparse to generate a "sparse object" file containing a list of symbols, then run the "linker" to unite those object files into bigger ones. This way, in the end we get a file containing all the global symbols appearing in the program. After learning more on the subject, I now agree that we should include the intermediate code representation into the object files. The implementation is built around a generic serialization mechanism [PATCH 01]. It handles many sorts of complex data structures, with pointers, cycles, unions, etc. E.g. it is able to serialize beasts like the sparse pointer lists. The price for this is a four byte overhead prepended to every serializable structure by the allocation wrapper. Also, you have to use a macro when declaring a serializable structure (or an array of such) statically. One limitation I was unable to overcome is the inability to work with structures used both stand-alone and embedded into bigger ones. Luckily, we have no such cases in the sparse codebase. The serializer produces C code, containing the data structures beind serialized. For the structure definitions, the generated code includes the original headers, defining the structures. After serializing a bunch of possibly interconnecded structures, and running cc over the generated code, one might get a static or dynamic library containing the copies of the serialized data structures, with all the pointer interconnections included. This way loading the data is trivial, and very memory efficient, and the whole dump-restore process should be totally transparent, e.g. it should be possible serialize the sparse() output, and run check_symbols() after loading the data from an other program. One thing that bothers me, is, if gcc would be able to process the huge data files, containing all the "code" of bigger projects like the Linux kernel. Will see. Being able to serialize any data, generating the symbol lists becomes as trivial as defining the data structures corresponding to source files and symbols [PATCH 06], deriving a symbol list from the sparse output, joining it into a ptr list and serializing it [PATCH 07]. The linker needs to dlopen the input "sparse objects", merge the symbol lists, and serialize the result [PATCH 08]. The generated code compilation is handled by the cgcc, cld and car wrappers [PATCH 09]. To look up symbols in sparse object files, a simple program is included [PATCH 10]. The plan is now to proceed with dumping the linearized code. Please take a look at the code, ask if anything needs clarification, and don't hesitate for criticism. If you've got ideas on how the linker might be extended and used, or have a different approach to the problem, please drop a message. You can also look at the code at http://svcs.cs.pdx.edu/gitweb?p=sparse-soc2008.git;a=shortlog;h=gsoc2008-linker or grab it from git://svcs.cs.pdx.edu/git/sparse-soc2008 branch gsoc2008-linker For those brave that would actually like to see how it works, that's how I'd run the thing over the sparse codebase: make CC="cgcc -v -emit-code" LD=cld AR=car and then ./where sparse.sparse.so linearize_statement And no, the patches are not ment for mainline inclusion right now. P.S: If you don't like being on the CC list, I'd miss your opinion, but would drop you from any further notifications on the project, just drop me a message. -- 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 alexey.zaytsev< at >gmail.com 2008-09-03T21:55:44 http://comments.gmane.org/gmane.comp.parsers.sparse/1485 Brett Nash 2008-09-02T23:31:57 http://comments.gmane.org/gmane.comp.parsers.sparse/1480 I have a situation here when $(CC) is called with -M options with slighly different set of -I/-D/etc arguments, which causes all sorts of funny reports from sparse. Also, this increases the overall build time because every compilation unit if sparsed twice. Signed-off-by: Alexander Shishkin <alexander.shishckin< at >gmail.com> --- cgcc | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/cgcc b/cgcc index 4fab530..89adbed 100755 --- a/cgcc +++ b/cgcc < at >< at > -7,6 +7,7 < at >< at > my $check = $ENV{'CHECK'} || 'sparse'; my $m32 = 0; my $m64 = 0; my $has_specs = 0; +my $gendeps = 0; my $do_check = 0; my $do_compile = 1; my $verbose = 0; < at >< at > -22,6 +23,7 < at >< at > foreach (< at >ARGV) { $m32 = 1 if /^-m32$/; $m64 = 1 if /^-m64$/; + $gendeps = 1 if /^-M$/; if (/^-specs=(.*)$/) { $check .= &add_specs ($1); < at >< at > -44,6 +46,11 < at >< at > foreach (< at >ARGV) { $check .= $this_arg unless &cc_only_option ($_); } +if ($gendeps) { + $do_compile = 1; + $do_check = 0; +} + if ($do_check) { if (!$has_specs) { $check .= &add_specs ('host_arch_specs'); Alexander Shishkin 2008-08-25T21:33:39 http://comments.gmane.org/gmane.comp.parsers.sparse/1476 Just building one directory of the kernel (./fs/*.c), ie "make bzImage C=1" generates more than 200 sparse warnings similar to warning: context imbalance in 'set_task_ioprio': wrong count at exit Even the simplest use cases throw this error e.g. fs/super.c line 162-164: static void put_super(struct super_block *sb) { spin_lock(&sb_lock); __put_super(sb); spin_unlock(&sb_lock); } It doesn't look like sparse has been fixed in a few months, unless the sparse tool repository has moved from the /pub/scm / devel/sparse/sparse.git directory on git.kernel.org Is there a way to turn just this warning off (the thousands of context imbalance messages generated by the kernel build make it harder to see real errors which sparse could catch)? Steve French 2008-08-19T21:47:29 http://comments.gmane.org/gmane.comp.parsers.sparse/1474 So, I'm new to Linux and to static analysis and so I'm sure I'm not the target audience for Sparse, but where is all the documentation? The website is well...sparse, the readme contains nothing helpful and neither does the FAQ. I compiled Sparse but I have no idea how to use it. There are all these binaries and none of them accept --help (except for test-suite). Am I missing something? Basically I'm trying to use Sparse to generate a call graph for a specific program. I tried using the graph binary which seems to generate XML-like code but my browser can't read it. Through browsing this message list I found that people were piping the results of graph through the binaries in the gvpr folder First of all, how am I supposed to have deduced that the output of graph needs to be further processed and that the binaries in gvpr are there for that purpose? Second, when I tried to do that I got an error saying that /usr/bin/gvpr doesn't exist. Do I need to move the gvpr folder to /usr/bin/ or is gvpr a separate program? My command is: ./graph flow.c | ./gvpr/return-paths I don't necesarily need an answer to my specific question, but if someone knows where to find a how-to or some other documentation that would be great. Thank you. -- 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 Ben Greenberg 2008-07-22T17:31:04 http://comments.gmane.org/gmane.comp.parsers.sparse/1465 Hi. Looking at cgcc, it seems that this code does not actually work, 26 if (/^-specs=(.*)$/) { 27 $check .= &add_specs ($1); 28 $has_specs = 1; 29 next; 30 } because add_specs() never expects to see a file name, and the option is removed from the argument list and never passed to gcc. As it seems that this feature never worked, probably we could simply remove it? Morten? --- Pass -specs to gcc without trying (and failing) to decompose it. Signed-off-by: Alexey Zaytsev <alexey.zaytsev< at >gmail.com> diff --git a/cgcc b/cgcc index 4fab530..a1d4f66 100755 --- a/cgcc +++ b/cgcc < at >< at > -23,12 +23,6 < at >< at > foreach (< at >ARGV) { $m32 = 1 if /^-m32$/; $m64 = 1 if /^-m64$/; - if (/^-specs=(.*)$/) { - $check .= &add_specs ($1); - $has_specs = 1; - next; - } Alexey Zaytsev 2008-07-20T18:28:35 http://comments.gmane.org/gmane.comp.parsers.sparse/1462 I got this error when running sparse on mips kernel with gcc 4.3: builtin:272:1: warning: Newline in string or character constant The linux-mips kernel uses '$(CC) -dM -E' to generates arguments for sparse. With gcc 4.3, it generates lot of '-D' options and causes pre_buffer overflow. The linux-mips kernel can filter unused symbols out to avoid overflow, but sparse should be fixed anyway. This patch make pre_buffer dynamically increasable and add extra checking for overflow instead of silently truncating. Signed-off-by: Atsushi Nemoto <anemo< at >mba.ocn.ne.jp> --- diff --git a/lib.c b/lib.c index 0abcc9a..6e8d09b 100644 --- a/lib.c +++ b/lib.c < at >< at > -186,7 +186,8 < at >< at > void die(const char *fmt, ...) } static unsigned int pre_buffer_size; -static char pre_buffer[8192]; +static unsigned int pre_buffer_alloc_size; +static char *pre_buffer; int Waddress_space = 1; int Wbitwise = 0; < at >< at > -232,12 +233,20 < at >< at > void add_pre_buffer(const char *fmt, ...) unsigned int size; va_start(args, fmt); +if (pre_buffer_alloc_size < pre_buffer_size + getpagesize()) { +pre_buffer_alloc_size += getpagesize(); +pre_buffer = realloc(pre_buffer, pre_buffer_alloc_size); +if (!pre_buffer) +die("Unable to allocate more pre_buffer space"); +} size = pre_buffer_size; size += vsnprintf(pre_buffer + size, -sizeof(pre_buffer) - size, +pre_buffer_alloc_size - size, fmt, args); pre_buffer_size = size; va_end(args); +if (pre_buffer_size >= pre_buffer_alloc_size - 1) +die("pre_buffer overflow"); } static char **handle_switch_D(char *arg, char **next) -- 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 Atsushi Nemoto 2008-07-19T15:22:24 http://comments.gmane.org/gmane.comp.parsers.sparse/1460 (if there's a good writeup on this, or a previous mailing post explaining this, a pointer to that will do just fine.) i'm trying to understand how this context checking is actually done by sparse. from the sparse man page: "Functions with the extended attribute __attribute__((context(expression,in_context,out_context)) require the context expression (for instance, a lock) to have the value in_context (a constant nonnegative integer) when called, and return with the value out_context (a constant nonnegative integer)." fair enough, but what are the possibilities for that "expression" and what exactly is being compared to the values of 0 or 1? sure, a lock is an obvious candidate, but you can't really simply be comparing the value of a lock to 0 or 1 -- a lock is a *structure* which doesn't have a simple value of 0 or 1. so, to try to keep things simple, what is happening in the background with code like this: ===== static void *aarp_seq_start(struct seq_file *seq, loff_t *pos) __acquires(aarp_lock) { struct aarp_iter_state *iter = seq->private; read_lock_bh(&aarp_lock); iter->table = resolved; iter->bucket = 0; return *pos ? iter_next(iter, pos) : SEQ_START_TOKEN; } ===== and how is that call to read_lock_bh() changing the "context" value of the object aarp_lock? thanks for any enlightenment. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== -- 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 Robert P. J. Day 2008-07-19T11:49:53 http://comments.gmane.org/gmane.comp.parsers.sparse/1457 I'm not sure how to resolve a situation like this: #include <linux/module.h> #include <linux/spinlock.h> MODULE_AUTHOR("Luis R. Rodriguez"); MODULE_LICENSE("GPL"); static spinlock_t some_lock; static void lock(int bh_flag) { if (bh_flag) spin_lock_bh(&some_lock); else spin_lock(&some_lock); } static void unlock(int bh_flag) { if (bh_flag) spin_unlock_bh(&some_lock); else spin_unlock(&some_lock); } static int hello_init(void) { spin_lock_init(&some_lock); lock(1); printk("I am a module, cheers!\n"); unlock(1); return 0; } static void goodbye_exit(void) { printk("Goodbye cruel world!\n"); } module_init(hello_init); module_exit(goodbye_exit); ---- Sparse complains with: /home/mcgrof/devel/spin_lock_sparse/sparse_spinlock.c:14:3: warning: context imbalance in 'lock': wrong count at exit /home/mcgrof/devel/spin_lock_sparse/sparse_spinlock.c:14:3: context 'lock': wanted 0, got 1 /home/mcgrof/devel/spin_lock_sparse/sparse_spinlock.c:20:3: warning: context problem in 'unlock': '_spin_unlock_bh' expected different context /home/mcgrof/devel/spin_lock_sparse/sparse_spinlock.c:20:3: context 'lock': wanted >= 1, got 0 You can test compile from files here: http://ruslug.rutgers.edu/~mcgrof/spin_lock_sparse/ Luis -- 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 Luis R. Rodriguez 2008-07-17T23:52:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.parsers.sparse