From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [xen-devel] [Patch v2 2/4] x86/stack: Adjust boundary conditions for printed stacks. Date: Mon, 12 Aug 2013 14:53:11 +0100 Message-ID: <5208E8C7.6090808@citrix.com> References: <5208CBB402000078000EB1D2@nat28.tlf.novell.com> <1376309700-18755-1-git-send-email-andrew.cooper3@citrix.com> <520902EF02000078000EB37E@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1V8sYp-0003IC-9r for xen-devel@lists.xenproject.org; Mon, 12 Aug 2013 13:53:27 +0000 In-Reply-To: <520902EF02000078000EB37E@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 12/08/13 14:44, Jan Beulich wrote: >>>> On 12.08.13 at 14:15, Andrew Cooper wrote: >> +/* >> + * Get the bottom-of-stack, as useful for printing stack traces. This is >> + * similar position as is returned by get_cpu_info(), but works on arbitrary >> + * stack pointer, rather than just the current. >> + * >> + * In the non-frame pointer case, the boundary is exactly at the cpu_info >> + * structure, which prevents the stack trace walker from mis-interpreting >> + * guest register as Xen return addresses. >> + * >> + * For the frame pointer case, the boundary is further adjusted by two words, >> + * as the call out of assembly does not contain a traditional C stack with >> + * frame pointers. >> + */ >> +#ifdef CONFIG_FRAME_POINTER >> +#define get_printable_stack_bottom(sp) \ >> + ((sp & (~(STACK_SIZE-1))) + \ >> + (STACK_SIZE - sizeof(struct cpu_info) - 2*sizeof(unsigned long))) >> +#else >> +#define get_printable_stack_bottom(sp) \ >> + ((sp & (~(STACK_SIZE-1))) + (STACK_SIZE - sizeof(struct cpu_info))) >> +#endif > Hmm, the delta being 2 slots makes no sense to me: The only > difference ought to be the saved frame pointer, i.e. one slot. > With what you propose here I'd suspect that the return address > pointing into assembly code might be lost now with frame pointers. > > Jan > It was never available, and I cant find a way of getting at it without special casing the frame-pointer code, or faking up a frame pointer in the assembly. ~Andrew