|
From: Yeshurun, M. <mei...@in...> - 2005-08-11 13:10:08
|
Thank you very much Tom, you were very helpful as usual.
The purpose of all this is to achieve what the VALGRIND_MALLOCLIKE_BLOCK
macros and friends are supposed to achieve, but without having to touch
the target program and libraries. (Modifying and recompiling Valgrind is
easier, thanks to you guys :)
This is not so important for STL allocators, but it is for other kinds
of allocators we use.
Regards,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Thursday, August 11, 2005 12:51 PM
To: val...@li...
Subject: Re: [Valgrind-users] Function redirection
In message
<942...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> I am trying to redirect an STL port allocator
(_STL::__node_alloc<true,
> 0>::allocate) to the same function that malloc is redirected to. I
> updated the functions and structures involved in the redirection
> mechanism.
Why are you trying to do that? It sounds like quite an odd thing to do?
> 29764-- REDIR sym to addr:
> soname:libstlport_gcc*:_ZN4_STL12__node_allocILb1ELi0EE8allocateEm to
> 0x140281D1E0
So the redirect is installed (but not resolved yet). The redirect is
from a library with an soname matching libstlport_gcc*.
> --29764-- Just loaded
>
/nfs/proj/dt/sc13/x86-64_linux26/STLport/4.5.2_64/lib/libstlport_gcc.so.
> 4.5 (soname=3D(null)),
>
> --29764-- resolving any unresolved redirs with it
>
> --29764-- Finished resolving
Now you loaded a library with no soname so the redirect won't match
and (as expected) we don't see any resolutions.
> Does this mean the redirection was successful?
No - you would see a "redir resolved" message if it was.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Yeshurun, M. <mei...@in...> - 2005-08-11 13:53:44
|
Thanks for the warning, but this wasn't such a big investment. I was surprised at how well-organized and documented Valgrind's source code is. Regards, Meir -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...]=20 Sent: Thursday, August 11, 2005 4:26 PM To: Yeshurun, Meir Cc: Tom Hughes; val...@li... Subject: RE: [Valgrind-users] Function redirection On Thu, 11 Aug 2005, Yeshurun, Meir wrote: > The purpose of all this is to achieve what the VALGRIND_MALLOCLIKE_BLOCK > macros and friends are supposed to achieve, but without having to touch > the target program and libraries. (Modifying and recompiling Valgrind is > easier, thanks to you guys :) Urk... don't be surprised if this doesn't work in future versions of=20 Valgrind. Relying on internal details like that is pretty gross. N |
|
From: Julian S. <js...@ac...> - 2005-08-11 14:08:39
|
On Thursday 11 August 2005 14:53, Yeshurun, Meir wrote: > Thanks for the warning, but this wasn't such a big investment. I was > surprised at how well-organized and documented Valgrind's source code > is. Well, that's very kind of you, but let me reiterate Nick's point: if you mess with internal interfaces, you can't have much expectation of your program continuing to work if/when that interface changes. J |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-12 02:09:54
|
What I was trying to say is, I don't mind. In this case, I don't think I had a choice but to "mess" with the internal interfaces.=20 Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Julian Seward Sent: Thursday, August 11, 2005 5:16 PM To: val...@li... Subject: Re: [Valgrind-users] Function redirection On Thursday 11 August 2005 14:53, Yeshurun, Meir wrote: > Thanks for the warning, but this wasn't such a big investment. I was > surprised at how well-organized and documented Valgrind's source code > is. Well, that's very kind of you, but let me reiterate Nick's point: if you mess with internal interfaces, you can't have much expectation of your program continuing to work if/when that interface changes. J ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-08-11 13:25:47
|
On Thu, 11 Aug 2005, Yeshurun, Meir wrote: > The purpose of all this is to achieve what the VALGRIND_MALLOCLIKE_BLOCK > macros and friends are supposed to achieve, but without having to touch > the target program and libraries. (Modifying and recompiling Valgrind is > easier, thanks to you guys :) Urk... don't be surprised if this doesn't work in future versions of Valgrind. Relying on internal details like that is pretty gross. N |