Documentation? Anywhere?

Documentation? Anywhere?

[Ben Greenberg]

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.

Re: Documentation? Anywhere?

[Josh Triplett]

On Tue, 2008-07-22 at 17:31 +0000, Ben Greenberg wrote:
> 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?

sparse and cgcc have manpages.  Other than that, you haven't missed
anything.

> 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

graph does not generate XML.  It generates graphviz output.  You need
graphviz to work with it; graphviz also includes gvpr.  You do not need
to process the output further; you simply have the option of doing so.
You can directly feed the output of graph to "dot" or one of the other
graphviz tools to get an image.

However, I agree that no obvious connection exists between the "graph"
program and the post-processing scripts in gvpr.

- Josh Triplett

Initializing float variables without type suffix

[Thomas Schmid]

Hello,

i think i found an error, when float variables are initialized.
Parsing the line

float var = 1.2345; 

creates a symbol "var", but the initializer (struct expression) is from 
type "EXPR_VALUE" - 
not "EXPR_FVALUE".
I think this happens, because the expression "1.2345" is interpreted as 
double and, as result of this, 
gets casted with the function cast_to(). It seems that cast_to() doesn't 
make double to float casts.

The result of this is, that if you want to show the initvalue of this 
symbol, "1" instead of "1.2345" is displayed.
If the variable is initialized with an additional type suffix, like 

float var = 1.2345F; 

or datatype double is used, it works.

Greetings,
Thomas Schmid

Re: Initializing float variables without type suffix

[Christopher Li]

On Wed, Feb 4, 2009 at 6:57 AM, Thomas Schmid
<Thomas.Schmid@br-automation.com> wrote:
> Hello,
>
> i think i found an error, when float variables are initialized.
> Parsing the line
>
> float var = 1.2345;
>
> gets casted with the function cast_to(). It seems that cast_to() doesn't
> make double to float casts.

cast_to() seems fine.

In expanding stage, cast_value() did not cast the constant
correctly.

Chris

[PATCH] Fix implicit cast to float (Was:Re: Initializing float variables without type suffix)

[Thomas Schmid]

christ.li@gmail.com schrieb am 06.02.2009 05:15:37:

> cast_to() seems fine.
> 
> In expanding stage, cast_value() did not cast the constant
> correctly.

You're right, I also noticed this in the meantime.
The decision, whether newtype is int_type or fp_type is not made 
correctly.

The following patch seems to work:

Fix implicit cast to float

Signed-Off-By: Thomas Schmid <Thomas.Schmid@br-automation.com>

Index: sparse/expand.c
===================================================================
--- sparse.orig/expand.c        2009-02-06 11:37:17.717913100 +0100
+++ sparse/expand.c     2009-02-06 11:37:34.973482600 +0100
@@ -116,7 +116,7 @@ Int:
        return;
 
 Float:
-       if (newtype->ctype.base_type != &fp_type) {
+       if (is_int_type(newtype)) {
                value = (long long)old->fvalue;
                expr->type = EXPR_VALUE;
                expr->taint = 0;
@@ -126,7 +126,7 @@ Float:
        if (oldtype->ctype.base_type != &fp_type)
                expr->fvalue = (long double)get_longlong(old);
        else
-               expr->fvalue = old->value;
+               expr->fvalue = old->fvalue;
 
        if (!(newtype->ctype.modifiers & MOD_LONGLONG)) {
                if ((newtype->ctype.modifiers & MOD_LONG))

Re: [PATCH] Fix implicit cast to float (Was:Re: Initializing float variables without type suffix)

[Christopher Li]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Fri, Feb 6, 2009 at 4:51 AM, Thomas Schmid
<Thomas.Schmid@br-automation.com> wrote:
> christ.li@gmail.com schrieb am 06.02.2009 05:15:37:
> -       if (newtype->ctype.base_type != &fp_type) {
> +       if (is_int_type(newtype)) {

I change your patch a little bit. The old logic of testing against float
type is better. The type can be a pointer for example. Then using
the long long value is more correct.

See the patch attached.

If there is not objections. I am going to apply this one.

Chris

[-- Attachment #2: Fix-implicit-cast-to-float-Was-Re-Initializing-float-variables-without-type-suffix.patch --]
[-- Type: application/octet-stream, Size: 3986 bytes --]

From patchwork Fri Feb  6 12:51:34 2009
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Fix implicit cast to float (Was:Re: Initializing float variables
	without type suffix)
Date: Fri, 06 Feb 2009 12:51:34 -0000
From: Thomas Schmid <Thomas.Schmid@br-automation.com>
X-Patchwork-Id: 5874

christ.li@gmail.com schrieb am 06.02.2009 05:15:37:

> cast_to() seems fine.
> 
> In expanding stage, cast_value() did not cast the constant
> correctly.

You're right, I also noticed this in the meantime.

The decision, whether newtype is int_type or fp_type is not made 
correctly.

The following patch seems to work:

Fix implicit cast to float

Modified by Chris.

Signed-Off-By: Thomas Schmid <Thomas.Schmid@br-automation.com>
Signed-Off-By: Christopher Li <sparse@chrisli.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Index: sparse.chrisl/evaluate.c
===================================================================
--- sparse.chrisl.orig/evaluate.c
+++ sparse.chrisl/evaluate.c
@@ -313,37 +313,6 @@ static struct expression * cast_to(struc
 	return expr;
 }
 
-static int is_type_type(struct symbol *type)
-{
-	return (type->ctype.modifiers & MOD_TYPE) != 0;
-}
-
-int is_ptr_type(struct symbol *type)
-{
-	if (type->type == SYM_NODE)
-		type = type->ctype.base_type;
-	return type->type == SYM_PTR || type->type == SYM_ARRAY || type->type == SYM_FN;
-}
-
-static inline int is_float_type(struct symbol *type)
-{
-	if (type->type == SYM_NODE)
-		type = type->ctype.base_type;
-	return type->ctype.base_type == &fp_type;
-}
-
-static inline int is_byte_type(struct symbol *type)
-{
-	return type->bit_size == bits_in_char && type->type != SYM_BITFIELD;
-}
-
-static inline int is_void_type(struct symbol *type)
-{
-	if (type->type == SYM_NODE)
-		type = type->ctype.base_type;
-	return type == &void_ctype;
-}
-
 enum {
 	TYPE_NUM = 1,
 	TYPE_BITFIELD = 2,
Index: sparse.chrisl/expand.c
===================================================================
--- sparse.chrisl.orig/expand.c
+++ sparse.chrisl/expand.c
@@ -116,17 +116,17 @@ Int:
 	return;
 
 Float:
-	if (newtype->ctype.base_type != &fp_type) {
+	if (!is_float_type(newtype)) {
 		value = (long long)old->fvalue;
 		expr->type = EXPR_VALUE;
 		expr->taint = 0;
 		goto Int;
 	}
 
-	if (oldtype->ctype.base_type != &fp_type)
+	if (!is_float_type(oldtype))
 		expr->fvalue = (long double)get_longlong(old);
 	else
-		expr->fvalue = old->value;
+		expr->fvalue = old->fvalue;
 
 	if (!(newtype->ctype.modifiers & MOD_LONGLONG)) {
 		if ((newtype->ctype.modifiers & MOD_LONG))
Index: sparse.chrisl/symbol.h
===================================================================
--- sparse.chrisl.orig/symbol.h
+++ sparse.chrisl/symbol.h
@@ -10,6 +10,7 @@
  */
 
 #include "token.h"
+#include "target.h"
 
 /*
  * An identifier with semantic meaning is a "symbol".
@@ -297,6 +298,37 @@ static inline int is_enum_type(const str
 	return (type->type == SYM_ENUM);
 }
 
+static inline int is_type_type(struct symbol *type)
+{
+	return (type->ctype.modifiers & MOD_TYPE) != 0;
+}
+
+static inline int is_ptr_type(struct symbol *type)
+{
+	if (type->type == SYM_NODE)
+		type = type->ctype.base_type;
+	return type->type == SYM_PTR || type->type == SYM_ARRAY || type->type == SYM_FN;
+}
+
+static inline int is_float_type(struct symbol *type)
+{
+	if (type->type == SYM_NODE)
+		type = type->ctype.base_type;
+	return type->ctype.base_type == &fp_type;
+}
+
+static inline int is_byte_type(struct symbol *type)
+{
+	return type->bit_size == bits_in_char && type->type != SYM_BITFIELD;
+}
+
+static inline int is_void_type(struct symbol *type)
+{
+	if (type->type == SYM_NODE)
+		type = type->ctype.base_type;
+	return type == &void_ctype;
+}
+
 static inline int get_sym_type(struct symbol *type)
 {
 	if (type->type == SYM_NODE)

Antwort: Re: [PATCH] Fix implicit cast to float (Was:Re: Initializing float variables without type suffix)

[Thomas Schmid]

christ.li@gmail.com schrieb am 09.02.2009 08:37:50:

> On Fri, Feb 6, 2009 at 4:51 AM, Thomas Schmid
> <Thomas.Schmid@br-automation.com> wrote:
> > christ.li@gmail.com schrieb am 06.02.2009 05:15:37:
> > -       if (newtype->ctype.base_type != &fp_type) {
> > +       if (is_int_type(newtype)) {
> 
> I change your patch a little bit. The old logic of testing against float
> type is better. The type can be a pointer for example. Then using
> the long long value is more correct.
> 
> See the patch attached.
> 
> If there is not objections. I am going to apply this one.

Thank you for correcting, your changes work fine for me.

There's only a little problem with the patch,
patch breaks off in evaluate.c, cause there's no function "is_void_type" 
within...

Greetings
Thomas Schmid

Re: Re: [PATCH] Fix implicit cast to float (Was:Re: Initializing float variables without type suffix)

[Christopher Li]

I guess you apply the patch on the official sparse's tree.

The patch is base on my development tree here:

http://git.kernel.org/?p=devel/sparse/chrisl/sparse.git;a=summary

is_type_void() is introduced at change 405cd6edfe2e88c808f0a45f0c2ef92a854dbe67,
warn about explicit usage of sizeof(void).

Chris

On Mon, Feb 9, 2009 at 5:38 AM, Thomas Schmid
<Thomas.Schmid@br-automation.com> wrote:
> christ.li@gmail.com schrieb am 09.02.2009 08:37:50:
>
>> On Fri, Feb 6, 2009 at 4:51 AM, Thomas Schmid
>> <Thomas.Schmid@br-automation.com> wrote:
>> > christ.li@gmail.com schrieb am 06.02.2009 05:15:37:
>> > -       if (newtype->ctype.base_type != &fp_type) {
>> > +       if (is_int_type(newtype)) {
>>
>> I change your patch a little bit. The old logic of testing against float
>> type is better. The type can be a pointer for example. Then using
>> the long long value is more correct.
>>
>> See the patch attached.
>>
>> If there is not objections. I am going to apply this one.
>
> Thank you for correcting, your changes work fine for me.
>
> There's only a little problem with the patch,
> patch breaks off in evaluate.c, cause there's no function "is_void_type"
> within...
>
> Greetings
> Thomas Schmid
>