From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9630 invoked by alias); 11 Jun 2012 15:24:52 -0000 Received: (qmail 9620 invoked by uid 22791); 11 Jun 2012 15:24:51 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO,TW_EG X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 15:24:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 11CC31C63B8; Mon, 11 Jun 2012 11:24:38 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LVtU7pBXi339; Mon, 11 Jun 2012 11:24:38 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D2FE31C6E1D; Mon, 11 Jun 2012 11:24:37 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 457B4145616; Mon, 11 Jun 2012 08:24:28 -0700 (PDT) Date: Mon, 11 Jun 2012 15:24:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: ping: [patch 2/2] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #5 Message-ID: <20120611152428.GB31854@adacore.com> References: <20120309210117.GB30432@host2.jankratochvil.net> <20120326190414.GB11001@host2.jankratochvil.net> <201203271853.q2RIrbWf024897@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203271853.q2RIrbWf024897@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2012-06/txt/msg00287.txt.bz2 Hi Jan, > So the simplified version below is perfectly adequate. We have some > freedom on where to place the breakpoint in the 16-byte stack gap we > create. I chose to put it up hight such that a small buffer overflow > isn't likely to overwrite the breakpoint instruction. Just wanted to make sure that you'd be OK with Mark's version of this part of your change... If that's the case, then all is good, and as soon as part #1 is good to go, so should this one. Thanks! > Index: i386-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/i386-tdep.c,v > retrieving revision 1.346 > diff -u -p -r1.346 i386-tdep.c > --- i386-tdep.c 29 Feb 2012 14:59:41 -0000 1.346 > +++ i386-tdep.c 27 Mar 2012 18:30:24 -0000 > @@ -2327,6 +2327,21 @@ i386_16_byte_align_p (struct type *type) > } > > static CORE_ADDR > +i386_push_dummy_code (struct gdbarch *gdbarch, CORE_ADDR sp, > + CORE_ADDR funcaddr, > + struct value **args, int nargs, > + struct type *value_type, > + CORE_ADDR *real_pc, CORE_ADDR *bp_addr, > + struct regcache *regcache) > +{ > + *bp_addr = sp - 1; > + *real_pc = funcaddr; > + > + /* Keep the stack aligned. */ > + return sp - 16; > +} > + > +static CORE_ADDR > i386_push_dummy_call (struct gdbarch *gdbarch, struct value *function, > struct regcache *regcache, CORE_ADDR bp_addr, int nargs, > struct value **args, CORE_ADDR sp, int struct_return, > @@ -7372,6 +7387,8 @@ i386_gdbarch_init (struct gdbarch_info i > set_gdbarch_get_longjmp_target (gdbarch, i386_get_longjmp_target); > > /* Call dummy code. */ > + set_gdbarch_call_dummy_location (gdbarch, ON_STACK); > + set_gdbarch_push_dummy_code(gdbarch, i386_push_dummy_code); > set_gdbarch_push_dummy_call (gdbarch, i386_push_dummy_call); > set_gdbarch_frame_align (gdbarch, i386_frame_align); > -- Joel