1:15 p.m.
I've slightly reworked how cpychecker tracks unknown values in
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=2...
For integer types, it now uses a new WithinRange abstract value,
describing the closed interval of possible values i.e.:
minvalue <= x <= maxvalue
For example, given this test case:
extern void __cpychecker_dump(int);
char array[12] = {2, 2, 2, 2, 8, 1, 8, 1, 8, 2, 8, 2};
char
test(int i)
{
__cpychecker_dump(i);
/* This ought to constrain i to within [0-255]: */
i = i & 0xff;
__cpychecker_dump(i);
/* and this ought to constrain it to within [0-7]: */
i = i >> 5;
__cpychecker_dump(i);
/* and hence this read is within the array bounds: */
return array[i];
}
we can see the values the analyzer knows about, using the "magic"
function __cpychecker_dump():
__dump((int)val [-0x80000000 <= val <= 0x7fffffff])
__dump((int)val [0 <= val <= 255])
__dump((int)val [0 <= val <= 7])
i.e. it starts by treating "i" as any possible int, but the mask against
0xff gives a new WithinRange(0, 255), and the right-shift constrains it
again.
In theory we can use this to do bounds-checking of array/buffer
accesses. I'm still working through the errors we were discussing in
the "python exceptions from refcount checker" thread, so I'm holding off
on implementing that yet.
I ran into this when compiling a fragment of code similar to the above
in gdb; the difference there is that the array was a local, initialized
within the function scope. cpychecker was complaining that the array
access was a read of an uninitialized value, since it wasn't able to
prove that "i" was within the bounds. Unfortunately, even with this
fix, it still complains, since it isn't smart enough to know that all
possible indices have an initialized value, and picks the "default"
value for the array, which is "uninitialized". Hopefully I can fix that
case too.
Dave
12:51 p.m.
David> For integer types, it now uses a new WithinRange abstract value,
David> describing the closed interval of possible values i.e.:
David> minvalue <= x <= maxvalue
It seems a shame that one cannot reuse the code tree-vrp.c for this.
It implies that you may end up rewriting many passes in Python for
similar reasons.
Tom
7:09 p.m.
On Fri, 2011-10-21 at 11:51 -0600, Tom Tromey wrote:
David> For integer types, it now uses a new WithinRange abstract
value,
David> describing the closed interval of possible values i.e.:
David> minvalue <= x <= maxvalue
It seems a shame that one cannot reuse the code tree-vrp.c for this.
It implies that you may end up rewriting many passes in Python for
similar reasons.
Agreed - though unfortunately the only thing exposed by tree-vrp.c seems
to be:
extern bool ssa_name_nonnegative_p (const_tree);
though it may be that we also get:
var = ASSERT_EXPR<>
statements added to the gimple by this pass.
I think I'm getting pulled between two goals here:
(a) writing the reference-count checker
(b) writing a more general-purpose static analyzer
The WithinRange stuff speaks to (b), and looking at tree-vrp.c, there
does seem to be a lot of overlap there (if you'll forgive the pun).
I think I need to focus back on (a) and making that work well; the
rather hokey way I've structured the checker is aimed at wrapper code,
where you have relatively simple functions that call into APIs (and leak
refcounts).
In the meantime, as of:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=e...
I've fixed up the "cpychecker" pass so that it can be run on an SSA
representation - but this isn't a real change - it still runs on the
pre-SSA representation unless you go into libcpychecker/__init__.py and
hack up the registration of the pass so that the pass is run later on.
I'm probably not familiar enough yet with all of GCC's various passes to
know where best to plug in the checker. Suggestions welcome. In
particular, I'm interested in tracking of pointer r-values, and the
l-values they point to.
I'm a little wary about moving the cpychecker pass later, though: my
understanding is that gcc's optimizations, like any good C compiler, may
make use of the fact that it's allowed to do what it likes with
undefined behaviors, and can make them do things that might be
surprising to the programmer, if it helps the machine code execute
faster for the well-defined cases. If I'm thinking this through
correctly, this seems at odds with the goals of static analysis: we're
especially interested in the undefined behaviors, and want to warn the
programmer about them. But I could be way off here.
Thoughts?
Dave
8:59 a.m.
>>>> "David" == David Malcolm
<dmalcolm(a)redhat.com> writes:
Tom> It seems a shame that one cannot reuse the code tree-vrp.c for this.
Tom> It implies that you may end up rewriting many passes in Python for
Tom> similar reasons.
David> Agreed - though unfortunately the only thing exposed by tree-vrp.c seems
David> to be:
David> extern bool ssa_name_nonnegative_p (const_tree);
David> though it may be that we also get:
David> var = ASSERT_EXPR<>
David> statements added to the gimple by this pass.
I think the ASSERT_EXPRs are removed at the end of the pass, so you'd
have to split the pass in two to access the info.
David> I think I'm getting pulled between two goals here:
David> (a) writing the reference-count checker
David> (b) writing a more general-purpose static analyzer
Yeah. And I think it makes sense to focus on (a) -- but also let gcc
upstream know of ways that gcc could be changed to make life easier for
plugin writers.
Tom
4580
days inactive
4591
days old
gcc-python-plugin@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
David Malcolm -
Tom Tromey