That would work well, I thought about it, the only issue I can think of is if you have a lib you load and then you unload it and load a second lib, you may have some name squashing. Basically whenever there's a dlopen, we would need to update the symbol table.
On 11-05-12 02:32 PM, Nils Carlson wrote: > Sorry for the outlook response... :-) > > Could maybe find a way to flush function names (and addresses) as metadata? > Will require some work, but should be feasible. Would require significant > post-processing. > > /Nils > > -----Original Message----- > From: Matthew Khouzam [mailto:[email protected]] > Sent: den 12 maj 2011 20:28 > To: [email protected] > Subject: Re: [ltt-dev] UST Instrumenting function entries and exits > > We could do a compromise and save the string the when there is a new address. > There are many caching schemes that can work. > > Thanks for the input Francis. > > On 11-05-12 02:18 PM, Francis Giraldeau wrote: >> On Thu, 2011-05-12 at 13:32 -0400, Matthew Khouzam wrote: >>> Hello world, >>> I just made a little program that I'm testing out and want some >>> opinions now that Mathieu D and Nils are not able to read their >>> emails. ;) >>> >>> This is a shared object (or code injected straight into the source) >>> that will allow ust calls to be hooked onto the function entries and exits. >> IMHO, this is truly a killer feature for UST! I wonder what is the >> performance difference between this technique with UST compared to >> gprof and callgrind (valgrind tool). >> >> For making this a real feature thought, it would be nice to save the >> address, not the string itself. Could it be convenient to save in the >> trace the function name string the first time the function is hit, >> then the symbol table at analysis time would not be required? >> >> Anyway, very interesting stuff! >> >> Francis >> >> >> _______________________________________________ >> ltt-dev mailing list >> [email protected] >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev > _______________________________________________ > ltt-dev mailing list > [email protected] > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
