headers
Jörn Engel | 11 Nov 14:56

Hard-coded gcc header path

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt | 11 Nov 07:24

inline declaration and assignment

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
Permalink | Reply | 1 comment |
headers
Blue Swirl | 2 Nov 09:34
Picon

[PATCH] Sparc64 (Sparc V9, LP64) support

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>
Attachment (sparse-sparc64.diff): plain/text, 982 bytes
Permalink | Reply | 0 comments |
headers
Blue Swirl | 2 Nov 09:29
Picon

[PATCH] OpenBSD support

Hi,

This patch adds OpenBSD support to sparse. I'm not subscribed, please CC.

Signed-off-by: Blue Swirl <blauwirbel <at> gmail.com>
Attachment (sparse-openbsd.diff): plain/text, 931 bytes
Permalink | Reply | 1 comment |
headers
Ben Dooks | 14 Sep 16:30

sparse 0.4.1 and __cold__

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

Q:      What's a light-year?
A:      One-third less calories than a regular year.
--
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
Permalink | Reply | 0 comments |
headers
David Given | 6 Sep 23:11

Odd behaviour with OP_SCAST

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Given | 6 Sep 18:00

Unused arg_count field

I notice that struct symbol::arg_count doesn't appear to be used,
anywhere. Is this obsolete?

--

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "All power corrupts, but we need electricity." --- Diana Wynne Jones,
│ _Archer's Goon_
Permalink | Reply | 1 comment |
headers
Christopher Li | 4 Sep 07:32

[2/2] The sparse byte code writer.

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Li | 4 Sep 07:32

[1/2] find ptr in a list

Signed-Off-By: Christopher Li <sparse <at> chrisli.org>
Attachment (find-ptr-in-list): application/octet-stream, 1197 bytes
Permalink | Reply | 0 comments |
headers
Christopher Li | 4 Sep 07:32

[0/2] RFC: sparse bytecode writer

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
Permalink | Reply | 0 comments |
headers
Christopher Li | 4 Sep 03:16

Fwd: [PATCH 0/10] Sparse linker

Oops, forget to CC the list.

Chris

---------- Forwarded message ----------
From: Chris Li <sparse <at> chrisli.org>
Date: Wed, Sep 3, 2008 at 6:08 PM
Subject: Re: [PATCH 0/10] Sparse linker
To: alexey.zaytsev <at> gmail.com

On Wed, Sep 3, 2008 at 2:55 PM,  <alexey.zaytsev <at> gmail.com> wrote:

> more on the subject, I now agree that we should include the
> intermediate code representation into the object files.

Good.

> for this is a four byte overhead prepended to every
> serializable structure by the allocation wrapper. Also, you

I would rather not have that 4 byte prepended to every
structure. Serialize is just one short stage of the life cycle
of those c structures. Having the permanent extra space
for just that is unnecessary. That 4 bytes meta data also
limits what C structure you can work on. All you need
is being able to map a point into some serialize object
to keep track which object is tracked and which one is not.

After you serialized the data. The meta data can be drop
completely. So the price to pay is for every unknown object
(Continue reading)

Permalink | Reply | 11 comments |

Gmane