|
From: Bart V. A. <bar...@gm...> - 2007-01-01 11:13:20
|
Another question: can a Valgrind tool be notified just after the debug information of the client has been loaded ? I need a point in the drd tool where I can iterate over the segments of the client to suppress conflict reports on the .got.plt section. This must happen before the client starts to dlopen() the DSO's it was linked with. Bart. |
|
From: Tom H. <to...@co...> - 2007-01-01 12:02:41
|
In message <e2e...@ma...>
"Bart Van Assche" <bar...@gm...> wrote:
> Another question: can a Valgrind tool be notified just after the debug
> information of the client has been loaded ? I need a point in the drd tool
> where I can iterate over the segments of the client to suppress conflict
> reports on the .got.plt section. This must happen before the client starts
> to dlopen() the DSO's it was linked with.
You mean after the main executable has been mapped and before any
shared libraries are mapped (even the ones it was linked with)?
That would basically mean after m_ume.c has mapped the program but
before we start it running (at which point ld-linux will immediately
start mapping the shared libraries it was linked with).
There's also the question of ld-linux.so (or whatever the interpreter
is called on the platform) as that will already have been mapped along
with the main program.
Also each shared library may have it's own .got.plt section if it
references functions in other shared libraries.
Can you not check for the PLT and suppress it when the access occurs
rather than trying to build suppressions up front?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2007-01-01 18:02:07
|
On Monday 01 January 2007 12:02, Tom Hughes wrote: > Can you not check for the PLT and suppress it when the access occurs > rather than trying to build suppressions up front? I agree, that sounds generally easier. You cannot really tell when a .so has been dlopen-d. You can ask (I believe) to be notified for mmap/munmap events, and maybe you can tell that they are of .so files. But it's still ugly: suppose a program mmaps a .so file for some other purpose -- eg to compute an md5sum of it. In short it's better not to put ELF-specific hacks in drd if you can avoid it - instead, think in terms of using/extending the interface provided by m_debuginfo. For one thing, not all current/potential future targets use ELF. J |