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

[Josef W. <Jos...@in...>]

On Monday 07 April 2003 16:55, Nicholas Nethercote wrote:
> 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.

I really see a problem if an application loads the same plugin multiple times 
in a row, and you get thus one plugin mapped multiple times simultaniously.
E.g. in KDevelop (a C++ IDE), every feature for project development is in a 
plugin. Now every time you open another project, the plugins of the old 
project are unmapped and the plugins of the new one are mapped (around 20).

It's easy to keep a list of objects the application has unmapped, and in a 
mmap, eventually return the already mapped object if a plugin is loaded a 
second time.

> 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

Why? If the same plugin is loaded at mostly once, I don't see a problem.

Josef

> lower half of my ever-growing todo list...
>
> N
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
--
Dipl.-Inform. Josef Weidendorfer
LRR-TUM - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454