This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: The further question.

> I am interested in what does gprof do when collecting tuning data?
> TBS(Time Bases Sampling) or Call Graph.

I'm not sure what you're asking. For call graph collection, mcount
does generates a list of caller/callee pairs (see the froms array).
Since this stuff is contributed by UC Berkeley, I guess you can find
papers about GNU profiling (anybody got references?)

I don't think gprof does TBS on its own, instead it uses the
profil(2/3) facility where available.

> For solaris, I can see at every function entry _mcount will invoke
> monstartup to start profilig(moncontrol does).I wonder how mcount
> sync with monstartup?

Looking at gmon-sol2.c, I see

/* Solaris 2 libraries use _mcount.  */
asm(".global _mcount; _mcount: mov %i7,%o1; mov %o7,%o0;b,a internal_mcount");
/* This is for compatibility with old versions of gcc which used mcount.  */
asm(".global mcount; mcount: mov %i7,%o1; mov %o7,%o0;b,a internal_mcount");

So every call to either mcoutn or _mcount goes to internal_mcount,
which does

        if(!already_setup) {
          extern char etext[];
          already_setup = 1;
          monstartup(0, (char *)etext);
          on_exit(_mcleanup, 0);

> How about multi-thread or multiprocess with gprof?

It looks like profiling does not work with
multithreading. Multiprocesses are not a problem, since there will be
a new copy of "already_setup" for each process.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]