Date: Thu, 14 Jul 2005 19:04:07 +0000 From: "Wojciech A. Koszek" <dunstan@freebsd.czest.pl> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/83445: [PATCH] ndis won't compile with kernel profiling enabled Message-ID: <20050714190407.GA32657@freebsd.czest.pl> In-Reply-To: <20050714232017.F2094@epsplex.bde.org> References: <200507141156.j6EBuIhU031586@freebsd.czest.pl> <20050714232017.F2094@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 14, 2005 at 11:50:59PM +1000, Bruce Evans wrote: > I think it would work with plain profiling (-p), but with high > resolution profiling (-pp), it would neither compile nor work, > since "ret" is a macro in that case in order to make it work. Hello, It compiles with -p, but not with -pp. > This would make high resolution profiling compile but not work. > There must be a call to mexitcount just before the return. > The ENTRY() macro hides the corresponding complications for > entry to functions and the ret macro handles most cases for > exit. > > Large amounts of assembler code are likely to have other bugs > in mcounting. The templates are especially difficult to handle > correctly -- gprof won't be able to find the addresses in code > constructed at runtime, so the runtime-only addresses should > somehow be mapped to compile-time addresses. I haven't notice that before, thanks. Main goal of my PR was to support kernel build process with profiling enabled. I think I have to deal with it by excluding ndis from build with WITHOUT_MODULES, which is acceptable for me. If noone is going to post additional comments and you agree, this PR can be closed now. -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050714190407.GA32657>