Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: jan.kratochvil@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: ping: [patch 2/2] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #5
Date: Tue, 27 Mar 2012 18:53:00 -0000	[thread overview]
Message-ID: <201203271853.q2RIrbWf024897@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20120326190414.GB11001@host2.jankratochvil.net> (message from	Jan Kratochvil on Mon, 26 Mar 2012 21:04:14 +0200)

> Date: Mon, 26 Mar 2012 21:04:14 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> --- a/gdb/i386-tdep.c
> +++ b/gdb/i386-tdep.c
> @@ -2326,6 +2326,30 @@ i386_16_byte_align_p (struct type *type)
>    return 0;
>  }
>  
> +/* Implementation for set_gdbarch_push_dummy_code.  */
> +
> +static CORE_ADDR
> +i386_push_dummy_code (struct gdbarch *gdbarch, CORE_ADDR sp, CORE_ADDR funaddr,
> +		      struct value **args, int nargs, struct type *value_type,
> +		      CORE_ADDR *real_pc, CORE_ADDR *bp_addr,
> +		      struct regcache *regcache)
> +{
> +  int bplen;
> +  CORE_ADDR bppc = sp;
> +
> +  gdbarch_breakpoint_from_pc (gdbarch, &bppc, &bplen);
> +  sp -= bplen;
> +
> +  /* amd64_push_dummy_call does alignment on its own but i386_push_dummy_call
> +     does not.  ABI requires stack alignment for executables using SSE.  */
> +  if (gdbarch_frame_align_p (gdbarch))
> +    sp = gdbarch_frame_align (gdbarch, sp);
> +
> +  *bp_addr = sp;
> +  *real_pc = funaddr;
> +  return sp;
> +}

You're almost certainly right worrying about stack alignment.
However, the comment doesn't make a lot of sense.  For one thing,
amd64_push_dummy_call() doesn't explicitly align the stack.  It just
preserves alignment.  Also, if i386_push_dummy_call() doesn't preserve
alignment (and it sure looks like it doesn't), then aligning the stack
here doesn't help.  In any case, we don't need to to explicitly align
the stack since that's already done bu call_function_by_hand().  So we
only need to make sure the stack stays aligned, which can be easily
done by always allocating 16 bytes of stack space.

Calling gdbarch_breakpoint_from_pc() is also a bit overkill.  The
breakpoint instruction on i386 is pretty much fixed, we know it is
just a single byte and we know it can be placed just about anywhere.

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.

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);
 


  reply	other threads:[~2012-03-27 18:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-09 21:01 Jan Kratochvil
2012-03-26 19:04 ` ping: " Jan Kratochvil
2012-03-27 18:53   ` Mark Kettenis [this message]
2012-06-11 15:24     ` Joel Brobecker
2012-06-11 19:10     ` Jan Kratochvil
2012-06-11 21:29       ` Mark Kettenis
2012-06-12  7:37         ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201203271853.q2RIrbWf024897@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox