Logging library calls

Thread View: comp.unix.programmer

5 messages

[T] Back to Threads [V] Tree View [G] Group Articles

5 total messages Started by isvara2005 Wed, 02 Nov 2005 12:17

#3490

Author: isvara2005
Date: Wed, 02 Nov 2005 12:17

16 lines
1997 bytes

In my program I would like to log (amongst other things) the time of
entry to and exit from pthread_mutex_lock. I currently do this by
modifiying the source code of the program, but I'd prefer to do it more
transparently. I could do this by LD_PRELOADing a shared object which
defines pthread_mutex_create and calls the real one by getting its
address using dlsym with RTLD_NEXT. No problems here.

However, this bit I'm not sure of. I also want the source file and line
number associated with either that call to pthread_mutex_lock, or the
definition of the pthread_mutex_t passed as an argument. Is it possible
to get that information from stabs or DWARF2 debugging symbols once
inside my wrapper function, or must I actually trace the execution of
the program?

Thanks for any info,
Dan.

Re: Logging library calls

#3491

Author: vineeth
Date: Wed, 02 Nov 2005 14:39

20 lines
2074 bytes

hi Dan,
   try callgrind [http://kcachegrind.sourceforge.net].
   callgrind will give you the info about time spent for each
instruction/function , but you cannot log anything.
fedora has callgrind and valgrind  by default.
just compile your program with debug info (-ggdb) and run it with
callgrind. (or valgrind --tool=cachegrind).
do the following ::
1) compile with debug info,
2) callgrind --trace-jump=yes --dump-instr=yes <program_name> <args>
3)you will get a file in cur dir , something like  callgrind.out.<pid>
4)kcachegrind callgrind.out.<pid>

in kcachegrind , you can view the time that was spent in each function.
it will display the call graph as well , but for that you need the dot
utilty, which can be obtained from http://graphviz.org.

hope this helps,
cheers,
vineeth.

Re: Logging library calls

#3492

Author: isvara2005
Date: Wed, 02 Nov 2005 15:55

11 lines
1833 bytes

Hi Vineeth,

I had considered the various valgrind tools. They're excellent in
general, and we have used them here, but because they run the program
in an emulated environment it runs very slowly. The particular program
I'm working on is fairly timing dependent (it's soft real-time) and
running too slowly for the entire test run will cause it to fail to
respond in time to anything, meaning that the wrong code paths will be
tested.

Dan.

Re: Logging library calls

#3493

Author: vineeth
Date: Wed, 02 Nov 2005 17:05

7 lines
1612 bytes

hi dan,
 you are right, even i have faced the same problem quite a few times.
how about trying *gprof* ? i have tried it very few times, but it think
it doesnt slow your program as much as valgrind.

regards,
vineeth.

Re: Logging library calls

#3494

Author: isvara2005
Date: Wed, 02 Nov 2005 17:30

15 lines
2211 bytes

Again, it's an option I had considered, but there are two problems
there. Firstly, "One problem with gprof under certain kernels (such as
Linux) is that it doesn't behave correctly with multithreaded
applications. It actually only profiles the main thread, which is quite
useless." (http://sam.zoy.org/writings/programming/gprof.html)

There appears to be at least one workaround for that, but the other
problem is that it involves recompiling the program and its shared
libraries (our libraries, that is, not system ones) with profiling
support. I'm trying to work towards a transparent, drop-in solution
that will work on existing executable images that are as close to what
we'd actually release as possible, hence looking for an
LD_PRELOAD-based solution.

Dan.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads