profiling with cc

[Marius Strobl]

On Mon, Feb 06, 2006 at 10:02:06PM +0100, Andreas Tobler wrote:
> Marius Strobl wrote:
> 
> > As far as I understand MCOUNT refers to the symbol generated by the
> > compiler and _MCOUNT_DECL to the name of the real function in libc.
> > As the compiler apparently generates calls to _mcount() on sparc64
> > the MCOUNT macro should define _mcount() for userland and _MCOUNT_DECL
> > mcount() or maybe better __mcount(). I'm not sure wheter the NetBSD
> > asm applies to FreeBSD.
> > If you let _MCOUNT_DECL define _mcount() as in your snippet above
> > you'll bypass the wrapper on sparc64 altogether.
> 
> Ok, my naive assumption that this will be easy, has gone :)
> 
> I do not yet understand the build process. Jumping into a 
> /usr/src/lib/libc and do a make picks up the system headers and not my 
> modified machine/profile.h. Going to /usr/src and do a make -DNO_CLEAN 
> all doesn't pick it up either.
> 
> What step do I miss? This is on CURRENT.
> 

If you just cd to src/lib/libc and issue make it's expected that the
system headers, i.e. the headers in /usr/include, are used as that's
basically the same as issuing make on any other source in any other
location. "Magic" regarding using the headers below src instead of
the system headers only happens when running a buildworld as then
(as far as I'm aware) a GCC with a special standard include path is
built and used.

> 
> P.S, even a pointer to read all through would be good.

Well, I think if you want to know how the build process works there's
no way around reading the Makefiles in src and /usr/share/mk/*.

Marius

-- 
This mail was scanned by AntiVir Milter.
This product is licensed for non-commercial use.
See www.antivir.de for details.