Re: [Valgrind-users] profiling/debugging inside shared objects

[Nicholas N. <nj...@ca...>]

On Mon, 7 Apr 2003, Josef Weidendorfer wrote:

> > Hmm, in theory there should be no problems, Valgrind (and hence
> > Cachegrind) can handle dlopen'd plugins ok...
>
> But they are unmapped before program termination. You only get one cost line
> "discarded" for all plugins. The solution would be to allow dumping while the
> plugin is mapped. Or you dump the information of BBCCs when the according
> object is unmapped.
>
> Or you don't delete BBCCs and accumate cost to "discarded", but keep them.
> Now you have the problem that a BB start address isn't unique to get to the
> right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish
> among BBs from different plugins at the same address.
>
> BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any
> BBCCs on unmapping, but still only uses the BB address. But checking the
> SegInfo* should be easy enough for a fix.
> Perhaps it's even better to take BBCCs of unmapped objects from the hash into
> a list, and put them in again if the object is mapped again after adjusting
> the addresses if needed. The same object could be mapped on a different base
> address.

Another approach:  I've been thinking about, and half-implemented, this
solution: when a program munmap()s an executable segment, Valgrind doesn't
really munmap it, but just leaves it in that address space.  Then the
symbols don't get unloaded.  The only downside is that it wastes address
space, but hopefully code sizes aren't so big that this is a problem.
One problem is that debug info is currently read in lazily, which clashes
with this, for tedious reasons. Getting back to this is somewhere in the
lower half of my ever-growing todo list...

N