Date: Tue, 7 Feb 2006 17:00:55 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Andreas Tobler <toa@pop.agri.ch> Cc: freebsd-sparc64@freebsd.org Subject: Re: profiling with cc Message-ID: <20060207170055.B53619@newtrinity.zeist.de> In-Reply-To: <43E7B94E.3070805@pop.agri.ch>; from toa@pop.agri.ch on Mon, Feb 06, 2006 at 10:02:06PM %2B0100 References: <43E3D228.6060801@pop.agri.ch> <20060205112432.A3868@newtrinity.zeist.de> <43E5D988.2070009@pop.agri.ch> <20060205122153.O68720@newtrinity.zeist.de> <43E5E70D.1090209@pop.agri.ch> <20060205132234.P68720@newtrinity.zeist.de> <43E60F45.4070004@pop.agri.ch> <20060205175656.S68720@newtrinity.zeist.de> <43E7B94E.3070805@pop.agri.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207170055.B53619>