From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 14 18:50:41 2005 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8011916A429 for ; Thu, 14 Jul 2005 18:50:41 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D952543D45 for ; Thu, 14 Jul 2005 18:50:40 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j6EJ4AGW032716; Thu, 14 Jul 2005 19:04:10 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j6EJ48WK032715; Thu, 14 Jul 2005 19:04:08 GMT (envelope-from dunstan) Date: Thu, 14 Jul 2005 19:04:07 +0000 From: "Wojciech A. Koszek" To: Bruce Evans Message-ID: <20050714190407.GA32657@freebsd.czest.pl> References: <200507141156.j6EBuIhU031586@freebsd.czest.pl> <20050714232017.F2094@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714232017.F2094@epsplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/83445: [PATCH] ndis won't compile with kernel profiling enabled X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 18:50:41 -0000 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