cvs commit: src/lib/libc/gmon mcount.c

[David Xu]

Bruce Evans wrote:

> 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.
>
First, my commit does not make it worse than before, there are two lines:
    if (p->state != GMON_PROF_ON)
                return;
which already added a bandaid.

I know function can be compiled without profiling. I don't think mcount
is to be used to record cpu time, it is only used for recording call graph,
cpu time is recorded by kernel's clock interrupt, if a function is called by
.mcount, its cpu time will be record by kernel, and because mcount is called
everywhere, I guess the final result will show those functions called by
mcount in gprof result, possible solution is inlining syscalls as assmeble
code in mcount.

> 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).

I don't think we want to create security risk, userland code can lockup
kernel.

> 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.
>
>> 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
>> problems.
>
>
> 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.
>
> it N layers deep.
>
>  
>
>
> 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 th
> 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
>   atomically.
>
> Bruce
>
>
>
Sorry, I have no plan to fix the old nasty problem,  you lose.