This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Deliberate padding between static and stack variables?


Hi,

I'm one of the developers of the Valgrind toolset.  Valgrind has two
tools, Memcheck and Addrcheck, that do memory checking of programs.  They
can detects overruns/underruns of heap blocks, because they replace the
standard versions of malloc() and friends with their own version, which
pads the start and end of heap blocks with 16 byte redzones, which are
marked as inaccessible.  They then track the addressability of every byte
of memory, and if an access to inaccessible memory (such as a heap
redzone) occurs, an error message is issued.

Pretty standard stuff.  But it doesn't work for static and stack
variables, because by the time Memcheck/Addrcheck see the program --
Valgrind tools don't do any recompiling or relinking, but use dynamic
binary translation to add the necessary instrumentation at runtime --
static and stack variables are already laid out, and adding redzones to
static memory and the stack is very difficult, because it would require
changing the code that accesses those variables.

What would be great is some co-operation from the compiler, which is
usually GCC.  Imagine if there was an option --pad-static-vars=N.  Then
Memcheck/Addrcheck could mark all the static variables as accessible --
using either symbol information or debugging information -- and all the
other parts of static memory could be marked as inaccessible.  (The 'N'
could let you choose the redzone size, in bytes.)  You could have a
similar option --pad-stack-vars=N for the stack, and Memcheck/Addrcheck
would handle those variables similarly.

And voila!  Memcheck/Addrcheck could detect static and stack overruns.
This would be very cool;  we just ran a survey of Valgrind users, and
several people stated that they wanted static and/or stack checking.

So I'm wondering how difficult these --pad options would be to implement?
I have very little idea about gcc's internals.  It seems like something
that could be quite easy... or quite hard.

Does anyone have any advice about this -- how hard it would be, and how
receptive the gcc team would be to adding options that help Valgrind tools
in this way?

N


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]