|
From: Julian S. <js...@ac...> - 2009-01-08 00:48:29
|
> >> - Buffers allocated on the stack with alloca() which is something
> >> that I don't have a good solution for.
> >
> > Hmm. I'd have thought that wouldn't be a problem. An access to an
> > unlabelled section on the stack would be considered "I don't know
> > what this is". Provided the same instruction continues to access
> > in an unlabelled section (until the frame exits) there should be no
> > error reported. An error is only reported for transitions from
> > known to unknown (or back) and for known-to-different-known areas.
> > (where "known" means "stack area associated with a known variable").
> >
> > But maybe it's more complex. Any possibility of a simple test case?
>
> Attached.
I tried an even simpler variant:
int main(int argc, char **argv)
{
char *s = alloca(200);
s[0] = 0; s[199] = 0;
return 0;
}
This gives a false error at -O0, but not at -O1 or above, on x86 and
amd64. Looking at the assembly code, I believe this is because at
-O1 and above, gcc 16-aligns 's' by doing
80483bc: 83 e0 f0 and $0xfffffff0,%eax
which causes it to continue to regard %eax as UNKNOWN (don't know
what it points at, so don't complain about references through it)
whereas at -O0 it does this:
80483c4: c1 e8 04 shr $0x4,%eax
80483c7: c1 e0 04 shl $0x4,%eax
The first shift causes the state to change from UNKNOWN to NONPTR
(everybody knows, if you right-shift a pointer, you no longer have
a point, correct?) and the shift left retains the NONPTRness, so it
then complains about references through it.
Rough. Perhaps transform the IR from the second version back to
the first version prior to instrumentation? Fragile. No easy answer
springs to mind.
J
|