From owner-freebsd-current Sun Feb 16 23:12: 0 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EE1637B401 for ; Sun, 16 Feb 2003 23:11:58 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BA0143F3F for ; Sun, 16 Feb 2003 23:11:57 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h1H7FCNk080567; Mon, 17 Feb 2003 02:15:12 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h1H7FC6b080566; Mon, 17 Feb 2003 02:15:12 -0500 (EST) Date: Mon, 17 Feb 2003 02:15:12 -0500 From: Jake Burkholder To: Bruce Evans Cc: Julian Elischer , FreeBSD current users Subject: Re: question on profiling code Message-ID: <20030217021512.O63597@locore.ca> References: <20030217162950.B4682-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030217162950.B4682-100000@gamplex.bde.org>; from bde@zeta.org.au on Mon, Feb 17, 2003 at 05:35:09PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100, Bruce Evans said words to the effect of; > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > In addupc_intr, if the increment cannot be done immediatly, the addres > > to increment the count for is stored and the increment is done later at > > ast or userret() time... > > Note that "cannot be done immediatly" is "always except on sparc64's" > under FreeBSD, since incrementing the counter immediately is only > implemented on sparc64's. > > > is there any reason that the address of the PC needs to be stored? > > why is the address from the frame at that time not useable? > > > > is it because the PC in the return frame may be hacked up for signals? > > That's was good a reason as any. I think the next return to user mode > is to the signal handler's context (if there is a signal to be handled). > It would be wrong to use the signal handler's pc. Also, ast() doesn't > have access to the frame, and there is no macro like CLKF_PC() for > general frames. This probably doesn't matter much, since signals are > rare and the hitting on the signal handler's pc would be perfectly > correct if the profiling interrupt occurred an instant later. There are macros for accessing trapframes, like the ones for clockframe, TRAPF_PC etc. > > Now there is a stronger reason: clock interrupt handling is "fast", > so it normally returns to user mode without going near ast(), and the > counter is not updated until the next non-fast interrupt or syscall. In freebsd "fast" interrupts do handle asts, on i386 they return through doreti (you may consider this a bug and have removed it in your version). I see no reason not to just use the pc in the trapframe passed to ast, even in the case of signals they won't be posted until after addupc_task is called. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message