|
From: Shujunjun <shu...@hu...> - 2015-03-30 03:30:16
|
Hi, Sorry for my first time send email to valgrind, if wrong, can you transmit this email to right people ? Thanks a lot. I have a problem when developing a valgrind tool(function_trace) for my business code. I want to trace a special function used in the guest program. For example, a function defined like this: msg_type * alloc_msg(char type, int num) When the guest program call this special function "alloc_msg", my valgrind tool can know the input args:"type" and "num", and when "alloc_msg" return, my valgrind tool can know the return value. Is there any way to implement it ? Or, which Valgrind tools(such as memcheck, callgrind) implement such functions ? I can learn from them. Or, do valgrind had interfaces to get such information? ps, I develop my valgrind tool base on "valgrind-3.10.1" download form "http://valgrind.org/" . Thank you for your help. shu...@hu...<mailto:shu...@hu...> Best Regards. |
|
From: John R. <jr...@bi...> - 2015-03-30 05:01:28
|
> I want to trace a special function used in the guest program. > For example, a function defined like this: > */msg_type * alloc_msg(char type, int num) > /*When the guest program call this special function "alloc_msg", my valgrind tool can know the input args:"type" and "num", and when "alloc_msg" return, my valgrind tool can know the return value. Note that in some cases similar functionality is provided outside of valgrind by tools such as ltrace. Also, using dlopen() with RTLD_NEXT enables the construction of a shared library that can "wrap" any call to a function that has dynamic linkage. Any call that goes through the PLT [ProgramLinkageTable] can be intercepted this way. Calls to a C static function cannot, nor calls to an inlined function. Once built, the shared library can be activated for any process without re-compilation or re-linking, by using the shell environment variable LD_PRELOAD. Consult "man dlopen" and search the 'net for a complete example. Both of these are not exactly what you asked for, but they are substantially similar in significant ways, avoid using valgrind altogether, and usually execute at least 10 times faster than valgrind. |
|
From: Shujunjun <shu...@hu...> - 2015-03-30 08:10:43
|
>Also, using dlopen() with RTLD_NEXT enables the construction of a shared library
that can "wrap" any call to a function that has dynamic linkage. Any call
that goes through the PLT [ProgramLinkageTable] can be intercepted this way.
Hi, John Reiser
Thanks a lot for your suggestion.
I think you give me a nice way to trace a function linked from a shared library.
But there some problems for me to using your method.
a. Trace a funtion's input and output is a part function of my tool, the tool will do some other function depend on valgrind, so I mybe still want to find a way to implement this function in valgrind if it can support.
b. The function I traced usually not linked from a shared library. Usually, it's a application level funtion and I as a tool developer cloud not force them change to a shared library.
So, I mybe still want to know: how can my valgrind tool know the input args and output value of a special guest function ?
shu...@hu...
Best Regards.
________________________________________
发件人: John Reiser [jr...@bi...]
发送时间: 2015年3月30日 13:01
收件人: val...@li...
主题: Re: [Valgrind-developers] Ask for how to know a function's input args and return value
> I want to trace a special function used in the guest program.
> For example, a function defined like this:
> */msg_type * alloc_msg(char type, int num)
> /*When the guest program call this special function "alloc_msg", my valgrind tool can know the input args:"type" and "num", and when "alloc_msg" return, my valgrind tool can know the return value.
Note that in some cases similar functionality is provided outside of valgrind
by tools such as ltrace.
Also, using dlopen() with RTLD_NEXT enables the construction of a shared library
that can "wrap" any call to a function that has dynamic linkage. Any call
that goes through the PLT [ProgramLinkageTable] can be intercepted this way.
Calls to a C static function cannot, nor calls to an inlined function.
Once built, the shared library can be activated for any process without
re-compilation or re-linking, by using the shell environment variable LD_PRELOAD.
Consult "man dlopen" and search the 'net for a complete example.
Both of these are not exactly what you asked for, but they are
substantially similar in significant ways, avoid using valgrind altogether,
and usually execute at least 10 times faster than valgrind.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers |