Date: Sun, 12 Feb 2006 23:14:24 +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: <20060212231423.M53619@newtrinity.zeist.de> In-Reply-To: <43EE7108.2040200@pop.agri.ch>; from toa@pop.agri.ch on Sun, Feb 12, 2006 at 12:19:36AM %2B0100 References: <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> <20060207170055.B53619@newtrinity.zeist.de> <43E8FC6B.50705@pop.agri.ch> <20060208173546.D53619@newtrinity.zeist.de> <43EE7108.2040200@pop.agri.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 12, 2006 at 12:19:36AM +0100, Andreas Tobler wrote:
> Marius Strobl wrote:
> > On Tue, Feb 07, 2006 at 09:00:43PM +0100, Andreas Tobler wrote:
> >> Attached what I have so far. I built a libc_p.a and I can compile some
> >> code with -pg and do some investigations with gprof now.
> >>
> >> Done on an enterprise 2 2x296MHz 896MB.
> >>
> >> FreeBSD enterprise.andreas.nets 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun
> >> Feb 5 08:20:12 CET 2006
> >> andreast@enterprise.andreas.nets:/usr/obj/home/andreast/devel/src/sys/GENERIC
> >> sparc64
> >>
> >> What I do not know yet, is the fact, how reliably the figures are.
> >>
> >
> > It should work fine for C functions but the ENTRY macro in
> > sparc64/include/asm.h has to be changed to call _mcount() so profiling
> > info is also gathered for asm functions (e.g. those in libc).
>
> Ok, after some reading I got confused.
>
> Do you expect an ENTRY for normal operation and one for PROFILED work?
An ENTRY_NOPROFILE which just never calls _mcount() and basically does
what ENTRY currently does and a new ENTRY that calls _mcount() depending
on whether GPROF is defined. I currently however don't see where/when
GPROF would be defined for userland so this might actually be only
relevant for kernel profiling. The latter would surprise me though.
> >
> >> Would you mind giving me some feedback if the attached is useful/needs
> >> rework?
> >>
> >
> > It has some style issues and inconsitencies (see style(9) and other
> > inline asm in e.g. sparc64/include/cpufunc.h). Otherwise it looks
> > good but probably needs a PIC version of the MCOUNT asm so it also
> > works when compiling with -p.
>
>
> Regarding inline asm, do you mean something like this:
> #define MCOUNT ({ \
> __asm __volatile( \
> " .global __mcount ; " \
> "__mcount: ; " \
> " add %o7, 8, %o1 ; " \
> "1: call 2f ; " \
> " nop ; " \
> "2: add %o7, _mcount - 1b, %o2 ; " \
> " ld [%o2], %o2 ; " \
> " jmpl %o2, %g0 ; " \
> " add %i7, 8, %o0 ; ");
> })
Yes, that's what I meant regarding the style of the inline asm. The
only minor issue in the above version is that the instruction which
is executed in the delay slot is not extra indented by one space.
>
> style 9 is good to have, but I seem to run in corner cases (my
> impression). It would be helpful for me to point out exactly what you
> mean I'm doing 'wrong'.
The other issue with your last patch was that you added macros with
#defined<space> and changed one that way while the rest of the file
adheres to style(9) and uses #define<tab>.
> Going through the code shows some
> inconsistencies and I am confused, as said ;)
Depends at what code you look at. F.e. the code in sys/kern and
sys/sparc64 generally pretty much adheres to style(9) while quite
a lot device drivers do not.
Regarding the sparc64 MCOUNT macro for userland I think it would
be better to follow the approach of the i386 version, i.e. to let
it define a C function and only determine frompc and selfpc via
inline asm instead of an asm function. That way we don't need to
distinguish between the PIC and !PIC case as the compiler will
do the necessary work for us. When compiling libc with -O2 GCC
generates exactly the same asm we'd do in the pure asm variant
for the !PIC case. For the PIC case the generated asm is even
better optimized as we could do in a generic way in a pure asm
variant.
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?20060212231423.M53619>