|
From: Jeremy F. <je...@go...> - 2002-10-29 22:49:41
|
One of the problems with the output from Helgrind (and memcheck) is that
the results are somewhat opaque. They talk about raw memory locations
rather than programmer-visible objects. If you're lucky, the location
is associated with a symbol, but mostly they're just offsets into
allocated memory, which isn't all that useful.
I'm thinking the best way of making this useful is by getting more
information out of the debug info (stabs or dwarf). The algorithm I'm
thinking about is:
- if the address is at or near a static/global symbol, look up the type
information for that symbol and work out either an array index and
structure member (if appropriate). So, for example, if the variable is
static int foo[5]; // at 0x4000
and the address is 0x4004, this would be currently presented as foo+4,
but we should display foo[1]. If foo is a structure:
struct { int a, b } foo[5]; // at 0x4000
and the address is 0x4004, we'd display foo[0].b
- if the address is in the heap, look at all the currently in-scope
local variables and see if they point near the address; if so, make up a
description based on that variable: "local->a" or "local[3].a". If
there's no locals which seem to be in the right area, we could look at
all the global and in-scope statics as well, but that might get
painful. Similarly with recurring into deep types (so we can discover
if "p->a->b->foo" is a good description for the address).
This all seems reasonably easy, on the assumption its easy to extract
more debug info out of our objects. This seems tricky. The stabs
reader in gdb (dbxread.c) is 115k of nasty GNU source. It seems to deal
with lots of bugs and special cases from stabs generated by compilers we
never have to deal with, but it still looks daunting.
So, does anyone have a feel for how hard this actually is?
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-10-30 13:33:25
|
On 29 Oct 2002, Jeremy Fitzhardinge wrote: > One of the problems with the output from Helgrind (and memcheck) is that > the results are somewhat opaque. They talk about raw memory locations > rather than programmer-visible objects. If you're lucky, the location > is associated with a symbol, but mostly they're just offsets into > allocated memory, which isn't all that useful. > > I'm thinking the best way of making this useful is by getting more > information out of the debug info (stabs or dwarf). > [...] > So, does anyone have a feel for how hard this actually is? No idea. But it would be a very useful thing; I can see this facility would definitely go in the core, as it could be useful for many skins. N |