From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24647 invoked by alias); 5 Jan 2007 14:36:49 -0000 Received: (qmail 24639 invoked by uid 22791); 5 Jan 2007 14:36:48 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 14:36:42 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 854B548CE55; Fri, 5 Jan 2007 09:36:40 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13497-01-6; Fri, 5 Jan 2007 09:36:40 -0500 (EST) Received: from takamaka.act-europe.fr (AStDenis-105-1-88-117.w80-8.abo.wanadoo.fr [80.8.217.117]) by nile.gnat.com (Postfix) with ESMTP id D5BF148CB9F; Fri, 5 Jan 2007 09:36:39 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 357D834C099; Fri, 5 Jan 2007 18:37:28 +0400 (RET) Date: Fri, 05 Jan 2007 14:36:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: PING: [RFA/i386] 2 more patterns in i386_analyze_stack_align Message-ID: <20070105143728.GV17211@adacore.com> References: <20061220104945.GB27642@adacore.com> <20061231060844.GP3640@adacore.com> <200612311215.kBVCF75Z010607@brahms.sibelius.xs4all.nl> <20070105064916.GS17211@adacore.com> <200701051104.l05B4xl1024647@brahms.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pyE8wggRBhVBcj8z" Content-Disposition: inline In-Reply-To: <200701051104.l05B4xl1024647@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00187.txt.bz2 --pyE8wggRBhVBcj8z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 486 > Ah wait, that's true even for "absolute" code. I had a quick look at > the GCC code and it seems to always treat %ebx as callee-saved. So > I'm happy with leaving it out, but you could add a comment saying so > to prevent us from having this same discussion in about two months > ;-). Sure! How does the attached patch look? Does it contain enough info? 2007-01-05 Joel Brobecker * i386-tdep.c (i386_analyze_stack_align): Add comment. -- Joel --pyE8wggRBhVBcj8z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="comment.diff" Content-length: 840 Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.227 diff -u -p -r1.227 i386-tdep.c --- i386-tdep.c 3 Jan 2007 19:01:25 -0000 1.227 +++ i386-tdep.c 5 Jan 2007 14:22:11 -0000 @@ -497,6 +497,10 @@ static CORE_ADDR i386_analyze_stack_align (CORE_ADDR pc, CORE_ADDR current_pc, struct i386_frame_cache *cache) { + /* The register used by the compiler to perform the stack re-alignment + is, in order of preference, either %ecx, %edx, or %eax. GCC should + never use %ebx as it always treats it as callee-saved, whereas + the compiler can only use caller-saved registers. */ static const gdb_byte insns_ecx[10] = { 0x8d, 0x4c, 0x24, 0x04, /* leal 4(%esp), %ecx */ 0x83, 0xe4, 0xf0, /* andl $-16, %esp */ --pyE8wggRBhVBcj8z--