cvs commit: src/lib/libc/gmon mcount.c
bde at zeta.org.au
Sat May 7 02:02:30 PDT 2005
On Sat, 7 May 2005, David Xu wrote:
> Bruce Evans wrote:
>> On Fri, 6 May 2005, David Xu wrote:
>>> Modified files:
>>> lib/libc/gmon mcount.c
>>> Fix race by using atomic operation, with this change, both libpthread
>>> and libthr now can run profiling on SMP.
>> Doesn't userland need to wait for mcount() to become unbusy, like the
>> does? Just returning gives broken profiling. mcount() takes a long time,
>> I don't know exactly how to avoid deadlock in userland. The kernel
>> just disables interrupts. Userland would have to stop rescheduling,
>> and do this without calling mcount() or dding much overhead. Note
Please trim quotes when replying so that further replies don't need to
do it N layers deep.
> First, this is a bandaid to avoid deadlock, the deadlock is easy
> to be reproduced.
That it is a bandaid should be mentioned in the log message.
> Also, userland is different with kernel on profiling. if I understand
> it correctly, I can not call other functions in mcount(), otherwise,
> the cputime of those functions will be at top of gprof result, for
> system scope thread, we can not disable rescheduling, only kernel
> can do this.
Functions can be called, but they must be compiled without profiling,
and if the functions are generally used then there should be special
versions of them for profiling so that profiling of their general
use doesn't get broken. In the kernel, this is handled by putting the
special versions in whole files and using the config directive
"profiling-routine" for the whole files, and mishandled for perfmon.c
by using "profiling-routine" for this file although the functions in it
are generally used. In userland, for mcount() itself, this is handled
by compiling mcount.c without profiling.
Disabling of scheduling for even system scope threads could probably
be handled by making a syscall to do it. The syscall would have to
be compiled without profiling. But this would be very inefficient
and migh cause security problems (it would let a thread prevent its
own rescheduling forever).
> Also, signal handler will cause mcount to be reentered
> with same thread, so we have to disable signal, but you know I can
> not call other functions to disable signal(I don't know how to
> handle this for M:N threads). so I don't know how to fix all these
Hmm, the problem is very old for signals, and the using busy state is
a quick fix for the problem that only works for the unthreaded case.
sigprocmask(2) can be used to disable signals -- mcount() just needs
to call a version of it compiled without profiling -- but this would
be inefficient in the same way as making syscalls to block rescheduling.
More ideas for bandaids:
- keep a count of calls to mcount() and report it later
- don't give up on flat profiling. It is easy to increment the counters
More information about the cvs-src