From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932069AbWERLVk (ORCPT ); Thu, 18 May 2006 07:21:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751340AbWERLVj (ORCPT ); Thu, 18 May 2006 07:21:39 -0400 Received: from mail.suse.de ([195.135.220.2]:30630 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S1751338AbWERLVj (ORCPT ); Thu, 18 May 2006 07:21:39 -0400 From: Andi Kleen To: "Jan Beulich" Subject: Re: [discuss] Re: [PATCH 2/3] reliable stack trace support (x86-64) Date: Thu, 18 May 2006 12:20:45 +0200 User-Agent: KMail/1.8 Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org References: <4469FC22.76E4.0078.0@novell.com> <200605161905.11907.ak@suse.de> <446C5C6E.76E4.0078.0@novell.com> In-Reply-To: <446C5C6E.76E4.0078.0@novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605181220.46037.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 18 May 2006 11:37, Jan Beulich wrote: > >>> Andi Kleen 16.05.06 19:05 >>> > > > >On Tuesday 16 May 2006 18:06, Jan Beulich wrote: > >> >>> Andi Kleen 16.05.06 17:13 >>> > >> > >> On Tuesday 16 May 2006 16:21, Jan Beulich wrote: > >> >> These are the x86_64-specific pieces to enable reliable stack traces. > >> >> The only restriction with this is that it currently cannot unwind > >> >> across the interrupt->normal stack boundary, as that transition is > >> >> lacking proper annotation. > >> > > >> >It would be nice if you could submit a patch to fix that. > >> > >> But I don't know how to fix it. See my other mail > > > >which mail? > > Reply to Ingo (with you on cc) regarding patch 1/3. Just saying that I > don't know much about expressions here. > Hmm, maybe we can find somebody who does. But then they would first need to be implemented in the unwinder anyways, I guess. Could be nasty agreed. > >> - I have no experience with expressions, nor have I ever seen them in > >> use. > > > >I remember Jim Houston used a hack of just loading the old stack into a > > register and defining that as a base register in CFI. I guess i would be > > willing to trade a few moves for that (should be pretty much free on a > > OOO CPU anyways) You think that trick would work? > > I don't think that would, because without CONFIG_DEBUG_INFO none of the > preserved registers get saved, hence there's no register to use for this. > Thus the price would not only be a move, but also a save/push and a > reload/pop. Three instructions? We might be still able to afford that. push/pop is probably not needed because the stack frame will be already set up (ok possibly after a few instructions, but a small window might be tolerable) > >> >> +#define UNW_PC(frame) (frame)->regs.rip > >> >> +#define UNW_SP(frame) (frame)->regs.rsp > >> > > >> >I think we alreay have instruction_pointer(). Better add a > >> > stack_pointer() in ptrace.h too. > >> > >> I could do that, but the macros will have to remain, as they don't > >> access pt_regs dierectly, so I guess it'd be pointless to change it. > > > >UNW_PC() is instruction_pointer(&frame->regs), isn't it? > > Yes. But the intention is that the user of UNW_PC doesn't need to know any > details of what fields frame has (i.e. the parameter of UNW_PC must only be > frame), so you can't replace it with instruction_pointer(). Maybe I'm dense but I still don't get - frame has a pt_regs so why isn't the caller allowed to know about that fact? -Andi