Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: Re: [patch i386, 0/2] skip insns generated by -fstack-protector
Date: Fri, 24 Dec 2010 09:15:00 -0000	[thread overview]
Message-ID: <4D145B02.8030507@codesourcery.com> (raw)
In-Reply-To: <4D145811.4060805@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On 12/24/2010 04:21 PM, Yao Qi wrote:
> Patch 1 is about fixing GDB analyze i386 prologue for insns and/add,
> which are part of i386 prologue, but GDB can't handle.

Here is a prologue generated by GCC, instructions on [1] can't be 
handled by GDB so far.  This patch is to handle them in prologue parsing.

      push   %ebp
      mov    %esp,%ebp

      and    $0xfffffff0,%esp  // <---- [1]
      add    $0xffffff80,%esp  // <---- [1]

      mov    %gs:0x14,%eax
      mov    %eax,0x7c(%esp)
      xor    %eax,%eax

      lea    0x54(%esp),%eax

Note that `and' instruction, for alignment, is not a must in prologue. 
My knowledge on i386 prologue is very limited and GCC i386 prologue 
generate is too complicated to understand for me, so I am not pretty 
sure on this patch.  I send it out, and your comments are appreciated.

-- 
Yao Qi

[-- Attachment #2: i386_prologue_parse_1224.patch --]
[-- Type: text/x-patch, Size: 3011 bytes --]

gdb/

	* i386-tdep.c (i386_analyze_frame_setup): Handle and/add
	sequence in prologue.

diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 4016a70..8c6f896 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -1263,6 +1263,7 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch,
   struct i386_insn *insn;
   gdb_byte op;
   int skip = 0;
+  int found_and_insn = 0;
 
   if (limit <= pc)
     return limit;
@@ -1332,24 +1333,71 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch,
       if (limit <= pc)
 	return limit;
 
-      /* Check for stack adjustment 
+      /* GCC may generate `and' instruction in front of stack adjustment for
+	 stack alignment.  Check for stack alignment, and skip it if any,
+
+         	and $0xfffffff0,%esp
+
+	 The change of ESP caused by this instruction is computed a little bit
+	 different here, because  we can't get value of offset from
+	 instruction itself.  We simulate the execution of this in struction
+	 to calcuate the delta change of ESP.  */
+      target_read_memory (pc, &op, 1);
+      /* `and' with signed 8-bit immediate.  */
+      if (op == 0x83)
+	{
+	  gdb_byte op1 = read_memory_unsigned_integer (pc + 1, 1, byte_order);
+
+	  if (op1 == 0xe4)
+	    {
+	      gdb_byte oprand
+		= read_memory_unsigned_integer (pc + 2, 1, byte_order);
+	      CORE_ADDR esp = cache->saved_regs[I386_ESP_REGNUM];
+
+	      found_and_insn = 1;
+	      /* Compute the delta change of esp .  */
+	      cache->locals = (esp & 0xff) - (esp & 0xff & oprand);
+	    }
+	}
+
+      /* Check for stack adjustment,
 
 	    subl $XXX, %esp
 
+	or
+
+	    add $0xffffff80, %esp
+
 	 NOTE: You can't subtract a 16-bit immediate from a 32-bit
 	 reg, so we don't have to worry about a data16 prefix.  */
-      target_read_memory (pc, &op, 1);
+
+      target_read_memory (pc + (found_and_insn ? 3 : 0), &op, 1);
       if (op == 0x83)
 	{
+	  gdb_byte op1
+	    = read_memory_unsigned_integer (pc + (found_and_insn ? 4 : 1),
+					    1, byte_order);
 	  /* `subl' with 8-bit immediate.  */
-	  if (read_memory_unsigned_integer (pc + 1, 1, byte_order) != 0xec)
-	    /* Some instruction starting with 0x83 other than `subl'.  */
-	    return pc;
-
-	  /* `subl' with signed 8-bit immediate (though it wouldn't
-	     make sense to be negative).  */
-	  cache->locals = read_memory_integer (pc + 2, 1, byte_order);
-	  return pc + 3;
+	  if (op1 == 0xec)
+	    {
+	      /* `subl' with signed 8-bit immediate (though it wouldn't
+		 make sense to be negative).  */
+	      cache->locals
+		= read_memory_integer (pc + (found_and_insn ? 5 : 2),
+				       1, byte_order);
+	      return pc + 3;
+	    }
+	  /* `add' with a 8-bit immediate.  */
+	  else if (op1 == 0xc4)
+	    {
+	      cache->locals
+		+= -1 * read_memory_integer (pc + (found_and_insn ? 5 : 2),
+					     1, byte_order);
+	      return pc + (found_and_insn ? 6 : 3);
+	    }
+	  /* Some instruction starting with 0x83 other than `subl' or
+	     `add'.  */
+	  return pc;
 	}
       else if (op == 0x81)
 	{

  reply	other threads:[~2010-12-24  8:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-24  8:42 Yao Qi
2010-12-24  9:15 ` Yao Qi [this message]
2010-12-24 11:28   ` Andreas Schwab
2010-12-25 14:03     ` Yao Qi
2010-12-24  9:36 ` [patch i386, 2/2] " Yao Qi
2011-01-04 15:22 ` [PING patch i386, 0/2] " Yao Qi
2011-01-13 11:56   ` Yao Qi

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=4D145B02.8030507@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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