|
From: Josef W. <Jos...@gm...> - 2005-10-02 23:06:34
|
On Saturday 01 October 2005 00:15, Josef Weidendorfer wrote: > Better would be to use GOT[1], as John Reiser pointed out, as this > has to contain a pointer to runtime_resolve, according to the ABI. Is there an easy way to get GOT[1] from a tool? I can sweep through the whole segment, checking with VG_(seginfo_sect_kind)(Addr) for the first address returning Vg_SectGOT, but that seems like wasting of time, as gotstart is a member of SegInfo. VG probably should provide iterator functions to allow a tool to browse through available debuginfo (as PIN has). Currently, we only have this for SegInfo via VG_(next_seginfo). What about SectInfo* VG_(first_sectinfo)(const SegInfo*); SectInfo* VG_(next_sectinfo)(const SectInfo*); Addr VG_(sectinfo_start)(const SectInfo*); SizeT VG_(sectinfo_size)(const SectInfo*); VgSectKind VG_(sectinfo_kind)(const SectInfo*); ? Similar for source files, debug lines, function symbols, data symbols... Perhaps this is overkill, and it should be only added when a tool ever will need it, as it probably has overhead. Another way would be to provide hooks for a tool to be notified about a debug info entry when being loaded, like SK_gotSymbol(const SegInfo*, const SymbolInfo*) with VG_(symbolinfo_name/kind/start/size). The tool could return a boolean to request that the SymbolInfo should be allocated until the segment is discarded. I really would like to add a callgrind mode being able to provide the info how often some data structure was accessed from which code. For this, I need above way to build up a structure for fast mapping of data addresses to data structure names. What is the general opinion here? Josef > I will look into this before the release. > > Josef > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |