This is the mail archive of the
mailing list for the glibc project.
gprof and LinuxThreads
- To: firstname.lastname@example.org
- Subject: gprof and LinuxThreads
- From: Xavier Leroy <Xavier.Leroy@inria.fr>
- Date: Wed, 13 Jan 1999 13:06:30 +0100
I have exchanged mail with some users about gprof(1) profiling of
multi-threaded programs under LinuxThreads. The conclusions so far
are as follows:
1- Each thread needs to do "moncontrol(1);" at start-up in order
to activate PC sampling for that thread. This could easily be done
in a profiling version of libpthread (libpthread_p.a ?)
2- PC sampling as implemented in sysdeps/posix/profil.c seems mostly
thread-safe. One could argue that the increment in profil_count
if (i < nsamples)
should be made atomic (using the <atomicity.h> macros), although
PC-sampling is statistical in nature and might tolerate occasional
lost increments due to race conditions.
3- mcount() as implemented in gmon/mcount.c is protected against
reentrant calls (via the compare_and_swap at the beginning),
but will not produce correct function call counts if several
threads call mcount() simultaneously (all but one return without
incrementing any counters). This is more problematic than
for profil_count, because users generally expect exact call counts
from gprof. But since mcount() can be called from a signal handler,
mutual exclusion in mcount() is out of the question, and rewriting
mcount() to use only atomic operations on lists seems quite hard.
A possible solution to 3- would be to have mcount as a weak alias for
__mcount. Then, LinuxThreads could redefine mcount to perform locking
around __mcount, except if mcount is called from a signal handler.
(LinuxThreads already maintains a per-thread "in signal handler" bit
for other purposes.)
Any opinions? I guess the question is: is it worth implementing 1-
in LinuxThreads before 3- is fixed?
All the best,