|
From: David G. <gr...@ob...> - 2005-09-14 18:13:13
|
I'm debugging a highly pthreaded code and Helgrind would be extremely
useful to me. Unfortunately it's disabled in 3.0.1. As the native
pthread ability fo 3.0.1 is valuable to me, I don't want to give that
up by going back to 2.2. Many bugs that were affecting me have been
fixed in later versions so giong back would be painful.
What's the status of getting Helgrind going again? Is it perhaps
working in CVS?
Thanks!
-Dave
|
|
From: Dirk M. <dm...@gm...> - 2005-09-14 18:21:03
|
On Wednesday 14 September 2005 20:12, David Greene wrote: > What's the status of getting Helgrind going again? Is it perhaps > working in CVS? No, no work has been done so far to reanimate helgrind. Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-09-14 20:13:28
|
On Wed, 14 Sep 2005, Dirk Mueller wrote: >> What's the status of getting Helgrind going again? Is it perhaps >> working in CVS? > > No, no work has been done so far to reanimate helgrind. It requires function wrapping to be implemented, so that it can detect the calling of all the pthread_* functions. (The native pthread support of 3.0.1 is exactly the change that caused Helgrind to no longer work.) I tried to implement function wrapping recently but my approach turned out to be flawed; it's harder than I thought. Helgrind won't work until this problem is solved. Nick |
|
From: Charlls Q. <cha...@ya...> - 2005-09-14 21:02:30
|
--- Nicholas Nethercote <nj...@cs...> escribió: > I tried to implement function wrapping recently but > my approach turned out > to be flawed; it's harder than I thought. Helgrind > won't work until this > problem is solved. Could you explain the notion of function wrapping? i dont know to you, but to me when a pathway is not clear at all or partially, it helps a lot explaining the problem to others, it makes the haze go away. And in the meantime we get enlightened ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |
|
From: Nicholas N. <nj...@cs...> - 2005-09-14 21:17:44
|
On Wed, 14 Sep 2005, Charlls Quarra wrote:
> Could you explain the notion of function wrapping? i
> dont know to you, but to me when a pathway is not
> clear at all or partially, it helps a lot explaining
> the problem to others, it makes the haze go away. And
> in the meantime we get enlightened
This option from the 'ld' man page is basically what we are trying to
achieve:
--wrap symbol
Use a wrapper function for symbol. Any undefined ref
erence to symbol will be resolved to "__wrap_symbol".
Any undefined reference to "__real_symbol" will be
resolved to symbol.
This can be used to provide a wrapper for a system
function. The wrapper function should be called
"__wrap_symbol". If it wishes to call the system
function, it should call "__real_symbol".
Here is a trivial example:
void *
__wrap_malloc (int c)
{
printf ("malloc called with %ld\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap
malloc, then all calls to "malloc" will call the func
tion "__wrap_malloc" instead. The call to
"__real_malloc" in "__wrap_malloc" will call the real
"malloc" function.
We have already a mechanism for redirecting all calls to a function to a
replacement version (eg. you call malloc and it ends up at __wrap_malloc).
The hard part is then being able to call __real_malloc from within
__wrap_malloc in a way that bypasses the redirection mechanism. (Without
the redirection bypassing, we end up in an infinite call loop.) The
problem is that we effectively need to store two different translations
(for __wrap_malloc and __real_malloc) for a single code address (malloc).
The code cache doesn't have a mechanism for this.
Nick
|
|
From: Ashley P. <as...@qu...> - 2005-09-15 12:05:06
|
On Wed, 2005-09-14 at 16:17 -0500, Nicholas Nethercote wrote: > We have already a mechanism for redirecting all calls to a function to a > replacement version (eg. you call malloc and it ends up at __wrap_malloc). > The hard part is then being able to call __real_malloc from within > __wrap_malloc in a way that bypasses the redirection mechanism. (Without > the redirection bypassing, we end up in an infinite call loop.) The > problem is that we effectively need to store two different translations > (for __wrap_malloc and __real_malloc) for a single code address (malloc). > The code cache doesn't have a mechanism for this. Why does __wrap_malloc() need to translate to malloc(), surely it's a case of adding extra code/address pairs rather then breaking the one-to-one mapping? I take it there's nothing in the weak stubs code which can help, I'm having trouble remembering how all this works with pthreads and I think only some of the pthread function are implemented that way anyway. Ashley, |
|
From: Tom H. <to...@co...> - 2005-09-15 12:12:56
|
In message <1126785880.15383.60.camel@localhost.localdomain>
Ashley Pittman <as...@qu...> wrote:
> On Wed, 2005-09-14 at 16:17 -0500, Nicholas Nethercote wrote:
>
>> We have already a mechanism for redirecting all calls to a function to a
>> replacement version (eg. you call malloc and it ends up at __wrap_malloc).
>> The hard part is then being able to call __real_malloc from within
>> __wrap_malloc in a way that bypasses the redirection mechanism. (Without
>> the redirection bypassing, we end up in an infinite call loop.) The
>> problem is that we effectively need to store two different translations
>> (for __wrap_malloc and __real_malloc) for a single code address (malloc).
>> The code cache doesn't have a mechanism for this.
>
> Why does __wrap_malloc() need to translate to malloc(), surely it's a
> case of adding extra code/address pairs rather then breaking the
> one-to-one mapping?
Nick was just giving an example of a similar technology, so it isn't a
good idea to get too bogged down in the details of it.
The basic issue is that we need a system that ensures that when the
client is about to execute a given function valgrind gets control and
can inspect the argument, cause a call to be made to the original
routine, and then get control back and inspect the result before
allowing the client to continue.
The current redirection model allows valgrind to replace a function
in the client program but not to observe it without replacing it.
> I take it there's nothing in the weak stubs code which can help, I'm
> having trouble remembering how all this works with pthreads and I think
> only some of the pthread function are implemented that way anyway.
We absolutely don't want to go back to the old model of trying to
preload code into the client and rely on symbol trickery - it was an
absolute nightmare.
We want something that hooks into the translation engine like the
current redirection and the prototype wrapping code that Jeremy
wrote for the old translation engine.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-09-15 14:28:30
|
On Thu, 15 Sep 2005, Ashley Pittman wrote: >> We have already a mechanism for redirecting all calls to a function to a >> replacement version (eg. you call malloc and it ends up at __wrap_malloc). >> The hard part is then being able to call __real_malloc from within >> __wrap_malloc in a way that bypasses the redirection mechanism. (Without >> the redirection bypassing, we end up in an infinite call loop.) The >> problem is that we effectively need to store two different translations >> (for __wrap_malloc and __real_malloc) for a single code address (malloc). >> The code cache doesn't have a mechanism for this. > > Why does __wrap_malloc() need to translate to malloc(), surely it's a > case of adding extra code/address pairs rather then breaking the > one-to-one mapping? I don't understand the question, sorry. Nick |
|
From: Ashley P. <as...@qu...> - 2005-09-15 14:50:22
|
On Thu, 2005-09-15 at 09:28 -0500, Nicholas Nethercote wrote: > On Thu, 15 Sep 2005, Ashley Pittman wrote: > > >> We have already a mechanism for redirecting all calls to a function to a > >> replacement version (eg. you call malloc and it ends up at __wrap_malloc). > >> The hard part is then being able to call __real_malloc from within > >> __wrap_malloc in a way that bypasses the redirection mechanism. (Without > >> the redirection bypassing, we end up in an infinite call loop.) The > >> problem is that we effectively need to store two different translations > >> (for __wrap_malloc and __real_malloc) for a single code address (malloc). > >> The code cache doesn't have a mechanism for this. > > > > Why does __wrap_malloc() need to translate to malloc(), surely it's a > > case of adding extra code/address pairs rather then breaking the > > one-to-one mapping? > > I don't understand the question, sorry. You said that __wrap_malloc() and __real_malloc() both need to point to a single code address (malloc). As far as I can see only __real_malloc() does, the other one needs to point elsewhere. Or is this translation for going the other way? /somewhat idle musings... Ashley, |