From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2952 invoked by alias); 31 Dec 2006 12:15:22 -0000 Received: (qmail 2942 invoked by uid 22791); 31 Dec 2006 12:15:21 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 31 Dec 2006 12:15:16 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id kBVCF8Q5031257; Sun, 31 Dec 2006 13:15:08 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id kBVCF75Z010607; Sun, 31 Dec 2006 13:15:07 +0100 (CET) Date: Sun, 31 Dec 2006 12:15:00 -0000 Message-Id: <200612311215.kBVCF75Z010607@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org In-reply-to: <20061231060844.GP3640@adacore.com> (message from Joel Brobecker on Sun, 31 Dec 2006 10:08:44 +0400) Subject: Re: PING: [RFA/i386] 2 more patterns in i386_analyze_stack_align References: <20061220104945.GB27642@adacore.com> <20061231060844.GP3640@adacore.com> 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: 2006-12/txt/msg00398.txt.bz2 > Date: Sun, 31 Dec 2006 10:08:44 +0400 > From: Joel Brobecker > > Ping? > > No rush. I just read a message from Mark saying that he was losing > messages, so I'm resending this message, JIC. Probably a good idea ;). > > Index: i386-tdep.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/i386-tdep.c,v > > retrieving revision 1.225 > > diff -u -p -r1.225 i386-tdep.c > > --- i386-tdep.c 8 Aug 2006 21:36:46 -0000 1.225 > > +++ i386-tdep.c 20 Dec 2006 10:21:58 -0000 > > @@ -497,15 +497,27 @@ static CORE_ADDR > > i386_analyze_stack_align (CORE_ADDR pc, CORE_ADDR current_pc, > > struct i386_frame_cache *cache) > > { > > - static const gdb_byte insns[10] = { > > + static const gdb_byte insns_ecx[10] = { > > 0x8d, 0x4c, 0x24, 0x04, /* leal 4(%esp), %ecx */ > > 0x83, 0xe4, 0xf0, /* andl $-16, %esp */ > > 0xff, 0x71, 0xfc /* pushl -4(%ecx) */ > > }; > > + static const gdb_byte insns_edx[10] = { > > + 0x8d, 0x54, 0x24, 0x04, /* leal 4(%esp), %edx */ > > + 0x83, 0xe4, 0xf0, /* andl $-16, %esp */ > > + 0xff, 0x72, 0xfc /* pushl -4(%edx) */ > > + }; > > + static const gdb_byte insns_eax[10] = { > > + 0x8d, 0x44, 0x24, 0x04, /* leal 4(%esp), %eax */ > > + 0x83, 0xe4, 0xf0, /* andl $-16, %esp */ > > + 0xff, 0x70, 0xfc /* pushl -4(%eax) */ > > + }; > > gdb_byte buf[10]; Hmm, you're missing the %ebx case here. Now on ELF systems, you'll probably never see it since %ebx is used for GOT access, but on other object formats I don't think there is any reason why GCC wouldn't choose to use %ebx as well. This looks reasonable otherwise, except that I would sort the patterns in a more logical order. Mark