Re: profiling

[Marcus Brinkmann]

On Mon, May 14, 2001 at 08:54:21PM +0200, Marcus Brinkmann wrote:
> when I try to compile a small test program with -pg, I get
> a statically linked exectuable (-lc_p) which is "Killed" in _start (c_p I
> have here is without debugging symbols, so I don't know where in _start, but
> the address was teh symbol address in objdump --syms output + 2).
> 
> When I modify the linking stage to link with -lc rather than -lc_p, I get a
> dynamically linked executable which works.  The gmon.out output can be used
> with gprof.

I think I have identified the problem.  For profiling, we link with gcrt1.o
rather than crt1.o (dynamic linking).  gcrt1.o contains gmon_start, which is
responsible to start up the profiler (see csu/gmon-start.c).

However, we don't use crt1.o for static linking, we need to use the special
crt0.o (sysdeps/mach/hurd/i386/static_start.S and the Makefile).

Now the crux.  When using -lc, we use shared linking, and gcrt1.o, which
works.  When using -lc_p, we *should* use something like crt0.o, but which
starts the profiler.  Let's call it gcrt0.o.

Unfortunately, such a thing doesn't exist.  So, it is not possible to link
with libc_p.a and have profiling working, because either you lack the
special static startup hack, or the gmon_startup component.

I will see if I can produce a working gcrt0.o.  Using -lc_p is essential for
us, because so much is implemented in glibc and we should really profile it.

That said, once we have gcrt0.o we also need to fix up the specs file.
It does not work correctly with -pg.  I think we should just do what Linux
does:  Use -pg for profiling just the program, and -profile if also libc
should be profiled.  If I understood it correctly.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de