Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Re: [RFA] Windows x64 SEH unwinder (v2)
@ 2013-08-19 15:14 Roland Schwingel
  2013-08-19 15:32 ` Tristan Gingold
  0 siblings, 1 reply; 12+ messages in thread
From: Roland Schwingel @ 2013-08-19 15:14 UTC (permalink / raw)
  To: Tristan Gingold
  Cc: Joel Brobecker, gdb-patches@sourceware.org ml, Pedro Alves

Hi Tristan...

 > > Stack frames are way better... Congratulations... But:
 > > When inspecting frames I see problems showing the content of
 > variables. I cannot look into any of the applications vars. gdb
 > just shows eg:
 >
 > > #1: 0x0000000000401577 in func4 (num=<error reading variable:
 > can't compute CFA for this frame>) at gdb_crash.c:26
 > >
 > > also a "p num" show the same error.
 > >
 > > Did I do something wrong? Is there a hidden trick that needs to be
 > applied to get this going that I couldn't find from reading the patch?
 >
 > Doesn't ring a bell here.  Can you post gdb_crash.c ?

The example program is part of my initial post.
(http://sourceware.org/ml/gdb/2005-04/msg00113.html)

For compiling it I simply did a
/path/to/my/x86_64-w64-mingw32-gcc.exe -g gdb_crash.c -o gdb_crash.exe

But the concrete example does not matter. Whichever program I compile 
variable viewing is totally broken for me (gcc 4.8.2 prelease 20130730 
with mingw-w64 runtime from 20130730) all with above error messages.

Thanks for your help. I hope this can be resolved soon. I would love to 
enrich my gdb with SEH2 unwinding!

Roland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-08-19 15:14 [RFA] Windows x64 SEH unwinder (v2) Roland Schwingel
@ 2013-08-19 15:32 ` Tristan Gingold
  0 siblings, 0 replies; 12+ messages in thread
From: Tristan Gingold @ 2013-08-19 15:32 UTC (permalink / raw)
  To: Roland Schwingel
  Cc: Joel Brobecker, gdb-patches@sourceware.org ml, Pedro Alves


On Aug 19, 2013, at 5:14 PM, Roland Schwingel <roland.schwingel@onevision.de> wrote:

> Hi Tristan...
> 
> > > Stack frames are way better... Congratulations... But:
> > > When inspecting frames I see problems showing the content of
> > variables. I cannot look into any of the applications vars. gdb
> > just shows eg:
> >
> > > #1: 0x0000000000401577 in func4 (num=<error reading variable:
> > can't compute CFA for this frame>) at gdb_crash.c:26
> > >
> > > also a "p num" show the same error.
> > >
> > > Did I do something wrong? Is there a hidden trick that needs to be
> > applied to get this going that I couldn't find from reading the patch?
> >
> > Doesn't ring a bell here.  Can you post gdb_crash.c ?
> 
> The example program is part of my initial post.
> (http://sourceware.org/ml/gdb/2005-04/msg00113.html)
> 
> For compiling it I simply did a
> /path/to/my/x86_64-w64-mingw32-gcc.exe -g gdb_crash.c -o gdb_crash.exe
> 
> But the concrete example does not matter. Whichever program I compile variable viewing is totally broken for me (gcc 4.8.2 prelease 20130730 with mingw-w64 runtime from 20130730) all with above error messages.
> 
> Thanks for your help. I hope this can be resolved soon. I would love to enrich my gdb with SEH2 unwinding!

I do not have this issue with the compiler installed here.

Can you send me (privately) your binary ?

Tristan.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
@ 2013-08-22 11:22 Roland Schwingel
  0 siblings, 0 replies; 12+ messages in thread
From: Roland Schwingel @ 2013-08-22 11:22 UTC (permalink / raw)
  To: Pedro Alves, gdb-patches@sourceware.org ml

Hi Pedro

 > > I think I understand the issue.
 > >
 > > This is caused by DW_OP_call_frame_cfa, which is supported only by
 > > the dwarf2 unwinder.
 > > This issue has been fixed in gcc (CL date is 2012-03-15).
 >
 > It took me a bit to dig out which patch that was, to understand
 > what the issue is.  For the benefit of others, it's here:
 > http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00980.html

This patch is already part of the gcc 4.8 I am using and is 
unfortunately not curing the problem. I will try tristan's new patch 
soon to see whether it is working now (where I do have a lot of 
convidence in).

Roland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-08-21 13:45 ` Tristan Gingold
@ 2013-08-22 10:22   ` Pedro Alves
  0 siblings, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2013-08-22 10:22 UTC (permalink / raw)
  To: Tristan Gingold; +Cc: Roland Schwingel, gdb-patches@sourceware.org ml

On 08/21/2013 02:45 PM, Tristan Gingold wrote:
> 
> On Aug 19, 2013, at 6:01 PM, Roland Schwingel <roland.schwingel@onevision.de> wrote:
> 
>> Hi Tristan,
>>
>>> I do not have this issue with the compiler installed here.
>>>
>>> Can you send me (privately) your binary ?
>> Sure. Will come in the next couple of minutes.
> 
> I think I understand the issue.
> 
> This is caused by DW_OP_call_frame_cfa, which is supported only by
> the dwarf2 unwinder.
> This issue has been fixed in gcc (CL date is 2012-03-15).

It took me a bit to dig out which patch that was, to understand
what the issue is.  For the benefit of others, it's here:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00980.html

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-08-19 16:01 Roland Schwingel
@ 2013-08-21 13:45 ` Tristan Gingold
  2013-08-22 10:22   ` Pedro Alves
  0 siblings, 1 reply; 12+ messages in thread
From: Tristan Gingold @ 2013-08-21 13:45 UTC (permalink / raw)
  To: Roland Schwingel, Pedro Alves; +Cc: gdb-patches@sourceware.org ml


On Aug 19, 2013, at 6:01 PM, Roland Schwingel <roland.schwingel@onevision.de> wrote:

> Hi Tristan,
> 
> > I do not have this issue with the compiler installed here.
> >
> > Can you send me (privately) your binary ?
> Sure. Will come in the next couple of minutes.

I think I understand the issue.

This is caused by DW_OP_call_frame_cfa, which is supported only by
the dwarf2 unwinder.
This issue has been fixed in gcc (CL date is 2012-03-15).

I see two ways to fix that issue:
* have a command to disable the SEH unwinder.  That will also add support
for gcc releases before 4.7
* handle seh unwinder in dwarf2_frame_cfa (not sure it is easy nor enough,
 so better to avoid this option).

Finally, we could ignore this issue and propose to backport (at least for
mingw64) the gcc patchlet.

Opinions ?

Tristan.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
@ 2013-08-19 16:01 Roland Schwingel
  2013-08-21 13:45 ` Tristan Gingold
  0 siblings, 1 reply; 12+ messages in thread
From: Roland Schwingel @ 2013-08-19 16:01 UTC (permalink / raw)
  To: Tristan Gingold; +Cc: gdb-patches@sourceware.org ml

Hi Tristan,

 > I do not have this issue with the compiler installed here.
 >
 > Can you send me (privately) your binary ?
Sure. Will come in the next couple of minutes.

Roland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-08-19 13:59                 ` Tristan Gingold
@ 2013-08-19 14:13                   ` Pedro Alves
  0 siblings, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2013-08-19 14:13 UTC (permalink / raw)
  To: Tristan Gingold; +Cc: gdb-patches@sourceware.org ml, Joel Brobecker

On 08/19/2013 02:59 PM, Tristan Gingold wrote:
> 
> On Jul 26, 2013, at 5:22 PM, Pedro Alves <palves@redhat.com> wrote:
>> What's the plan for debugging binaries with dwarf instead of SEH?
>> That'd be binaries built with gcc 4.6, IIUC.
>> There was the fallback idea of providing a knob to disable the
>> unwinder.  Is that no longer necessary?  Did you guys manage to
>> confirm what happens with those binaries?  Or will we take the wait
>> until someone complains the missing support approach?  If the latter,
>> than I think NEWS should mention we no longer support such binaries.
>> Now that I mention that, I notice the NEWS hunk is mentioned in the
>> ChangeLog, but it's actually missing from the patch.  :-)
> 
> I'd simply vote for not supporting binaries built with old versions of gcc.
> If a user complain, we can either add a command to disable the SEH unwinder,
> or (and I prefer that option) simply say: sorry, but your binary is not
> compliant with the x64 ABI.

That's fine with me, but I do think that if going that direction,
then it'd be nicer to users to mention it in NEWS now, so they
may know upfront they'll need to upgrade their compiler (and stick
with older gdbs for older binaries).

Thanks,
-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-07-26 15:22               ` Pedro Alves
@ 2013-08-19 13:59                 ` Tristan Gingold
  2013-08-19 14:13                   ` Pedro Alves
  0 siblings, 1 reply; 12+ messages in thread
From: Tristan Gingold @ 2013-08-19 13:59 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches@sourceware.org ml, Joel Brobecker


On Jul 26, 2013, at 5:22 PM, Pedro Alves <palves@redhat.com> wrote:

> On 07/08/2013 11:55 AM, Tristan Gingold wrote:
>> Hello,
>> 
>> this is the second version of the patch we submitted in January.
>> I have rewritten amd64_windows_frame_decode_epilogue according to the
>> very serious review and comments from Pedro.
> 
> Thanks!
> 
> (That was here, for reference:
> http://sourceware.org/ml/gdb-patches/2013-01/msg00165.html
> I had to go back and read it again, I had already swapped out
> all my SEH knowledge :-) )

:-)

> What's the plan for debugging binaries with dwarf instead of SEH?
> That'd be binaries built with gcc 4.6, IIUC.
> There was the fallback idea of providing a knob to disable the
> unwinder.  Is that no longer necessary?  Did you guys manage to
> confirm what happens with those binaries?  Or will we take the wait
> until someone complains the missing support approach?  If the latter,
> than I think NEWS should mention we no longer support such binaries.
> Now that I mention that, I notice the NEWS hunk is mentioned in the
> ChangeLog, but it's actually missing from the patch.  :-)

I'd simply vote for not supporting binaries built with old versions of gcc.
If a user complain, we can either add a command to disable the SEH unwinder,
or (and I prefer that option) simply say: sorry, but your binary is not
compliant with the x64 ABI.

> Otherwise I have no further comments.  It looks good to me.

Ok, will commit it then (with the NEWS hunk).

Tristan.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-08-05 11:25 Roland Schwingel
@ 2013-08-19 13:53 ` Tristan Gingold
  0 siblings, 0 replies; 12+ messages in thread
From: Tristan Gingold @ 2013-08-19 13:53 UTC (permalink / raw)
  To: Roland Schwingel
  Cc: Pedro Alves, Joel Brobecker, gdb-patches@sourceware.org ml


On Aug 5, 2013, at 1:24 PM, Roland Schwingel <roland.schwingel@onevision.de> wrote:

> Hi Tristan...
> 
> gdb-patches-owner@sourceware.org wrote on 08.07.2013 12:55:21:
> 
> > Hello,
> >
> > this is the second version of the patch we submitted in January.
> > I have rewritten amd64_windows_frame_decode_epilogue according to the
> > very serious review and comments from Pedro.
> >
> > Tristan.
> Today I gave your SEH unwinder patch a try. I hopped to get an issue from 2005 resolved.
> 
> (See: http://sourceware.org/ml/gdb/2005-04/msg00113.html)
> 
> I compiled my test C code from this post using GCC 4.8.1 for x64 windows
> with no special options beside of a single -g.
> 
> Stack frames are way better... Congratulations... But:
> When inspecting frames I see problems showing the content of variables. I cannot look into any of the applications vars. gdb just shows eg:
> 
> #1: 0x0000000000401577 in func4 (num=<error reading variable: can't compute CFA for this frame>) at gdb_crash.c:26
> 
> also a "p num" show the same error.
> 
> Did I do something wrong? Is there a hidden trick that needs to be applied to get this going that I couldn't find from reading the patch?

Doesn't ring a bell here.  Can you post gdb_crash.c ?

Tristan.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
@ 2013-08-05 11:25 Roland Schwingel
  2013-08-19 13:53 ` Tristan Gingold
  0 siblings, 1 reply; 12+ messages in thread
From: Roland Schwingel @ 2013-08-05 11:25 UTC (permalink / raw)
  To: Tristan Gingold, Pedro Alves
  Cc: Joel Brobecker, gdb-patches@sourceware.org ml

Hi Tristan...

gdb-patches-owner@sourceware.org wrote on 08.07.2013 12:55:21:

 > Hello,
 >
 > this is the second version of the patch we submitted in January.
 > I have rewritten amd64_windows_frame_decode_epilogue according to the
 > very serious review and comments from Pedro.
 >
 > Tristan.
Today I gave your SEH unwinder patch a try. I hopped to get an issue 
from 2005 resolved.

(See: http://sourceware.org/ml/gdb/2005-04/msg00113.html)

I compiled my test C code from this post using GCC 4.8.1 for x64 windows
with no special options beside of a single -g.

Stack frames are way better... Congratulations... But:
When inspecting frames I see problems showing the content of variables. 
I cannot look into any of the applications vars. gdb just shows eg:

#1: 0x0000000000401577 in func4 (num=<error reading variable: can't 
compute CFA for this frame>) at gdb_crash.c:26

also a "p num" show the same error.

Did I do something wrong? Is there a hidden trick that needs to be 
applied to get this going that I couldn't find from reading the patch?

Thanks for your help,

Roland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFA] Windows x64 SEH unwinder (v2)
  2013-07-08 10:55             ` [RFA] Windows x64 SEH unwinder (v2) Tristan Gingold
@ 2013-07-26 15:22               ` Pedro Alves
  2013-08-19 13:59                 ` Tristan Gingold
  0 siblings, 1 reply; 12+ messages in thread
From: Pedro Alves @ 2013-07-26 15:22 UTC (permalink / raw)
  To: Tristan Gingold; +Cc: gdb-patches@sourceware.org ml, Joel Brobecker

On 07/08/2013 11:55 AM, Tristan Gingold wrote:
> Hello,
> 
> this is the second version of the patch we submitted in January.
> I have rewritten amd64_windows_frame_decode_epilogue according to the
> very serious review and comments from Pedro.

Thanks!

(That was here, for reference:
 http://sourceware.org/ml/gdb-patches/2013-01/msg00165.html
 I had to go back and read it again, I had already swapped out
 all my SEH knowledge :-) )

What's the plan for debugging binaries with dwarf instead of SEH?
That'd be binaries built with gcc 4.6, IIUC.
There was the fallback idea of providing a knob to disable the
unwinder.  Is that no longer necessary?  Did you guys manage to
confirm what happens with those binaries?  Or will we take the wait
until someone complains the missing support approach?  If the latter,
than I think NEWS should mention we no longer support such binaries.
Now that I mention that, I notice the NEWS hunk is mentioned in the
ChangeLog, but it's actually missing from the patch.  :-)

Otherwise I have no further comments.  It looks good to me.

-- 
Pedro Alves


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [RFA] Windows x64 SEH unwinder (v2)
  2013-01-10 16:24           ` Pedro Alves
@ 2013-07-08 10:55             ` Tristan Gingold
  2013-07-26 15:22               ` Pedro Alves
  0 siblings, 1 reply; 12+ messages in thread
From: Tristan Gingold @ 2013-07-08 10:55 UTC (permalink / raw)
  To: gdb-patches@sourceware.org ml; +Cc: Joel Brobecker, Pedro Alves

Hello,

this is the second version of the patch we submitted in January.
I have rewritten amd64_windows_frame_decode_epilogue according to the
very serious review and comments from Pedro.

Tristan.

2013-07-08  Tristan Gingold  <gingold@adacore.com>

	* NEWS: Add entry mentioning support for native Windows x64
	SEH data. 

	* amd64-windows-tdep.c: #include "objfiles.h", "frame-unwind.h",
	"coff/internal.h", "coff/i386.h", "coff/pe.h" and "libcoff.h".
	(struct amd64_windows_frame_cache): New struct.
	(amd64_windows_w2gdb_regnum): New global.
	(pc_in_range, amd64_windows_frame_decode_epilogue)
	(amd64_windows_frame_decode_insns, amd64_windows_find_unwind_info)
	(amd64_windows_frame_cache, amd64_windows_frame_prev_register)
	(amd64_windows_frame_this_id): New functions.
	(amd64_windows_frame_unwind): New static global.
	(amd64_windows_skip_prologue): New function.
	(amd64_windows_init_abi): Call frame_unwind_prepend_unwinder
	with amd64_windows_frame_unwind. Call set_gdbarch_skip_prologue
	with amd64_windows_skip_prologue.

Index: amd64-windows-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-windows-tdep.c,v
retrieving revision 1.16
diff -u -r1.16 amd64-windows-tdep.c
--- amd64-windows-tdep.c	8 Apr 2013 19:59:08 -0000	1.16
+++ amd64-windows-tdep.c	8 Jul 2013 10:49:37 -0000
@@ -25,6 +25,12 @@
 #include "regcache.h"
 #include "windows-tdep.h"
 #include "frame.h"
+#include "objfiles.h"
+#include "frame-unwind.h"
+#include "coff/internal.h"
+#include "coff/i386.h"
+#include "coff/pe.h"
+#include "libcoff.h"
 
 /* The registers used to pass integer arguments during a function call.  */
 static int amd64_windows_dummy_call_integer_regs[] =
@@ -155,6 +161,752 @@
   return pc;
 }
 
+struct amd64_windows_frame_cache
+{
+  /* ImageBase for the module.  */
+  CORE_ADDR image_base;
+
+  /* Function start and end rva.  */
+  CORE_ADDR start_rva;
+  CORE_ADDR end_rva;
+
+  /* Next instruction to be executed.  */
+  CORE_ADDR pc;
+
+  /* Current sp.  */
+  CORE_ADDR sp;
+
+  /* Address of saved integer and xmm registers.  */
+  CORE_ADDR prev_reg_addr[16];
+  CORE_ADDR prev_xmm_addr[16];
+
+  /* These two next fields are set only for machine info frames.  */
+
+  /* Likewise for RIP.  */
+  CORE_ADDR prev_rip_addr;
+
+  /* Likewise for RSP.  */
+  CORE_ADDR prev_rsp_addr;
+
+  /* Address of the previous frame.  */
+  CORE_ADDR prev_sp;
+};
+
+/* Convert a Windows register number to gdb.  */
+static const enum amd64_regnum amd64_windows_w2gdb_regnum[] =
+{
+  AMD64_RAX_REGNUM,
+  AMD64_RCX_REGNUM,
+  AMD64_RDX_REGNUM,
+  AMD64_RBX_REGNUM,
+  AMD64_RSP_REGNUM,
+  AMD64_RBP_REGNUM,
+  AMD64_RSI_REGNUM,
+  AMD64_RDI_REGNUM,
+  AMD64_R8_REGNUM,
+  AMD64_R9_REGNUM,
+  AMD64_R10_REGNUM,
+  AMD64_R11_REGNUM,
+  AMD64_R12_REGNUM,
+  AMD64_R13_REGNUM,
+  AMD64_R14_REGNUM,
+  AMD64_R15_REGNUM
+};
+
+/* Return TRUE iff PC is the the range of the function corresponding to
+   CACHE.  */
+
+static int
+pc_in_range (CORE_ADDR pc, const struct amd64_windows_frame_cache *cache)
+{
+  return (pc >= cache->image_base + cache->start_rva
+	  && pc < cache->image_base + cache->end_rva);
+}
+
+/* Try to recognize and decode an epilogue sequence.
+
+   Return -1 if we fail to read the instructions for any reason.
+   Return 1 if an epilogue sequence was recognized, 0 otherwise.  */
+
+static int
+amd64_windows_frame_decode_epilogue (struct frame_info *this_frame,
+				     struct amd64_windows_frame_cache *cache)
+{
+  /* According to MSDN an epilogue "must consist of either an add RSP,constant
+     or lea RSP,constant[FPReg], followed by a series of zero or more 8-byte
+     register pops and a return or a jmp".
+
+     Furthermore, according to RtlVirtualUnwind, the complete list of
+     epilog marker is:
+     - ret                      [c3]
+     - ret n                    [c2 imm16]
+     - rep ret                  [f3 c3]
+     - jmp imm8 | imm32         [eb rel8] or [e9 rel32]
+     - jmp qword ptr imm32                 - not handled
+     - rex.w jmp reg            [4X ff eY]
+  */
+
+  CORE_ADDR pc = cache->pc;
+  CORE_ADDR cur_sp = cache->sp;
+  struct gdbarch *gdbarch = get_frame_arch (this_frame);
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+  gdb_byte op;
+  gdb_byte rex;
+
+  /* We don't care about the instruction deallocating the frame:
+     if it hasn't been executed, the pc is still in the body,
+     if it has been executed, the following epilog decoding will work.  */
+
+  /* First decode:
+     -  pop reg                 [41 58-5f] or [58-5f].  */
+
+  while (1)
+    {
+      /* Read opcode. */
+      if (target_read_memory (pc, &op, 1) != 0)
+	return -1;
+
+      if (op >= 0x40 && op <= 0x4f)
+	{
+	  /* REX prefix.  */
+	  rex = op;
+
+	  /* Read opcode. */
+	  if (target_read_memory (pc + 1, &op, 1) != 0)
+	    return -1;
+	}
+      else
+	rex = 0;
+
+      if (op >= 0x58 && op <= 0x5f)
+	{
+	  /* pop reg  */
+	  gdb_byte reg = (op & 0x0f) | ((rex & 1) << 3);
+
+	  cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp;
+	  cur_sp += 8;
+	}
+      else
+	break;
+
+      /* Allow the user to break this loop.  This shouldn't happen as the
+	 number of consecutive pop should be small.  */
+      QUIT;
+    }
+
+  /* Then decode the marker.  */
+
+  /* Read opcode.  */
+  if (target_read_memory (pc, &op, 1) != 0)
+    return -1;
+
+  switch (op)
+    {
+    case 0xc3:
+      /* Ret.  */
+      cache->prev_rip_addr = cur_sp;
+      cache->prev_sp = cur_sp + 8;
+      return 1;
+
+    case 0xeb:
+      {
+	/* jmp rel8  */
+	gdb_byte rel8;
+	CORE_ADDR npc;
+
+	if (target_read_memory (pc + 1, &rel8, 1) != 0)
+	  return -1;
+	npc = pc + 2 + (signed char) rel8;
+
+	/* If the jump is within the function, then this is not a marker,
+	   otherwise this is a tail-call.  */
+	return !pc_in_range (npc, cache);
+      }
+
+    case 0xec:
+      {
+	/* jmp rel32  */
+	gdb_byte rel32[4];
+	CORE_ADDR npc;
+
+	if (target_read_memory (pc + 1, rel32, 4) != 0)
+	  return -1;
+	npc = pc + 5 + extract_signed_integer (rel32, 4, byte_order);
+
+	/* If the jump is within the function, then this is not a marker,
+	   otherwise this is a tail-call.  */
+	return !pc_in_range (npc, cache);
+      }
+
+    case 0xc2:
+      {
+	/* ret n  */
+	gdb_byte imm16[2];
+
+	if (target_read_memory (pc + 1, imm16, 2) != 0)
+	  return -1;
+	cache->prev_rip_addr = cur_sp;
+	cache->prev_sp = cur_sp
+	  + extract_unsigned_integer (imm16, 4, byte_order);
+	return 1;
+      }
+
+    case 0xf3:
+      {
+	/* rep; ret  */
+	gdb_byte op1;
+
+	if (target_read_memory (pc + 2, &op1, 1) != 0)
+	  return -1;
+	if (op1 != 0xc3)
+	  return 0;
+
+	cache->prev_rip_addr = cur_sp;
+	cache->prev_sp = cur_sp + 8;
+	return 1;
+      }
+
+    case 0x40:
+    case 0x41:
+    case 0x42:
+    case 0x43:
+    case 0x44:
+    case 0x45:
+    case 0x46:
+    case 0x47:
+    case 0x48:
+    case 0x49:
+    case 0x4a:
+    case 0x4b:
+    case 0x4c:
+    case 0x4d:
+    case 0x4e:
+    case 0x4f:
+      /* Got a REX prefix, read next byte.  */
+      rex = op;
+      if (target_read_memory (pc + 1, &op, 1) != 0)
+	return -1;
+
+      if (op == 0xff)
+	{
+	  /* rex jmp reg  */
+	  gdb_byte op1;
+	  unsigned int reg;
+	  gdb_byte buf[8];
+
+	  if (target_read_memory (pc + 2, &op1, 1) != 0)
+	    return -1;
+	  return (op1 & 0xf8) == 0xe0;
+	}
+      else
+	return 0;
+
+    default:
+      /* Not REX, so unknown.  */
+      return 0;
+    }
+}
+
+/* Decode and execute unwind insns at UNWIND_INFO.  */
+
+static void
+amd64_windows_frame_decode_insns (struct frame_info *this_frame,
+				  struct amd64_windows_frame_cache *cache,
+				  CORE_ADDR unwind_info)
+{
+  CORE_ADDR save_addr = 0;
+  CORE_ADDR cur_sp = cache->sp;
+  struct gdbarch *gdbarch = get_frame_arch (this_frame);
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+  int j;
+
+  for (j = 0; ; j++)
+    {
+      struct external_pex64_unwind_info ex_ui;
+      /* There are at most 256 16-bit unwind insns.  */
+      gdb_byte insns[2 * 256];
+      gdb_byte *p;
+      gdb_byte *end_insns;
+      unsigned char codes_count;
+      unsigned char frame_reg;
+      unsigned char frame_off;
+
+      /* Read and decode header.  */
+      if (target_read_memory (cache->image_base + unwind_info,
+			      (gdb_byte *) &ex_ui, sizeof (ex_ui)) != 0)
+	return;
+
+      if (frame_debug)
+	fprintf_unfiltered
+	  (gdb_stdlog,
+	   "amd64_windows_frame_decodes_insn: "
+	   "%s: ver: %02x, plgsz: %02x, cnt: %02x, frame: %02x\n",
+	   paddress (gdbarch, unwind_info),
+	   ex_ui.Version_Flags, ex_ui.SizeOfPrologue,
+	   ex_ui.CountOfCodes, ex_ui.FrameRegisterOffset);
+
+      /* Check version.  */
+      if (PEX64_UWI_VERSION (ex_ui.Version_Flags) != 1)
+	return;
+
+      if (j == 0
+	  && (cache->pc >=
+	      cache->image_base + cache->start_rva + ex_ui.SizeOfPrologue))
+	{
+	  /* Not in the prologue.  We want to detect if the PC points to an
+	     epilogue. If so, the epilogue detection+decoding function is
+	     sufficient.  Otherwise, the unwinder will consider that the PC
+	     is in the body of the function and will need to decode unwind
+	     info.  */
+	  if (amd64_windows_frame_decode_epilogue (this_frame, cache) == 1)
+	    return;
+
+	  /* Not in an epilog.  Clear possible side effects.  */
+	  memset (cache->prev_reg_addr, 0, sizeof (cache->prev_reg_addr));
+	}
+
+      codes_count = ex_ui.CountOfCodes;
+      frame_reg = PEX64_UWI_FRAMEREG (ex_ui.FrameRegisterOffset);
+
+      if (frame_reg != 0)
+	{
+	  /* According to msdn:
+	     If an FP reg is used, then any unwind code taking an offset must
+	     only be used after the FP reg is established in the prolog.  */
+	  gdb_byte buf[8];
+	  int frreg = amd64_windows_w2gdb_regnum[frame_reg];
+
+	  get_frame_register (this_frame, frreg, buf);
+	  save_addr = extract_unsigned_integer (buf, 8, byte_order);
+
+	  if (frame_debug)
+	    fprintf_unfiltered (gdb_stdlog, "   frame_reg=%s, val=%s\n",
+				gdbarch_register_name (gdbarch, frreg),
+				paddress (gdbarch, save_addr));
+	}
+
+      /* Read opcodes.  */
+      if (codes_count != 0
+	  && target_read_memory (cache->image_base + unwind_info
+				 + sizeof (ex_ui),
+				 insns, codes_count * 2) != 0)
+	return;
+
+      end_insns = &insns[codes_count * 2];
+      for (p = insns; p < end_insns; p += 2)
+	{
+	  int reg;
+
+	  if (frame_debug)
+	    fprintf_unfiltered
+	      (gdb_stdlog, "   op #%u: off=0x%02x, insn=0x%02x\n",
+	       (unsigned) (p - insns), p[0], p[1]);
+
+	  /* Virtually execute the operation.  */
+	  if (cache->pc >= cache->image_base + cache->start_rva + p[0])
+	    {
+	      /* If there is no frame registers defined, the current value of
+		 rsp is used instead.  */
+	      if (frame_reg == 0)
+		save_addr = cur_sp;
+
+	      switch (PEX64_UNWCODE_CODE (p[1]))
+		{
+		case UWOP_PUSH_NONVOL:
+		  /* Push pre-decrements RSP.  */
+		  reg = amd64_windows_w2gdb_regnum[PEX64_UNWCODE_INFO (p[1])];
+		  cache->prev_reg_addr[reg] = cur_sp;
+		  cur_sp += 8;
+		  break;
+		case UWOP_ALLOC_LARGE:
+		  if (PEX64_UNWCODE_INFO (p[1]) == 0)
+		    cur_sp +=
+		      8 * extract_unsigned_integer (p + 2, 2, byte_order);
+		  else if (PEX64_UNWCODE_INFO (p[1]) == 1)
+		    cur_sp += extract_unsigned_integer (p + 2, 4, byte_order);
+		  else
+		    return;
+		  break;
+		case UWOP_ALLOC_SMALL:
+		  cur_sp += 8 + 8 * PEX64_UNWCODE_INFO (p[1]);
+		  break;
+		case UWOP_SET_FPREG:
+		  cur_sp = save_addr
+		    - PEX64_UWI_FRAMEOFF (ex_ui.FrameRegisterOffset) * 16;
+		  break;
+		case UWOP_SAVE_NONVOL:
+		  reg = amd64_windows_w2gdb_regnum[PEX64_UNWCODE_INFO (p[1])];
+		  cache->prev_reg_addr[reg] = save_addr
+		    - 8 * extract_unsigned_integer (p + 2, 2, byte_order);
+		  break;
+		case UWOP_SAVE_NONVOL_FAR:
+		  reg = amd64_windows_w2gdb_regnum[PEX64_UNWCODE_INFO (p[1])];
+		  cache->prev_reg_addr[reg] = save_addr
+		    - 8 * extract_unsigned_integer (p + 2, 4, byte_order);
+		  break;
+		case UWOP_SAVE_XMM128:
+		  cache->prev_xmm_addr[PEX64_UNWCODE_INFO (p[1])] =
+		    save_addr
+		    - 16 * extract_unsigned_integer (p + 2, 2, byte_order);
+		  break;
+		case UWOP_SAVE_XMM128_FAR:
+		  cache->prev_xmm_addr[PEX64_UNWCODE_INFO (p[1])] =
+		    save_addr
+		    - 16 * extract_unsigned_integer (p + 2, 4, byte_order);
+		  break;
+		case UWOP_PUSH_MACHFRAME:
+		  if (PEX64_UNWCODE_INFO (p[1]) == 0)
+		    {
+		      cache->prev_rip_addr = cur_sp + 0;
+		      cache->prev_rsp_addr = cur_sp + 24;
+		      cur_sp += 40;
+		    }
+		  else if (PEX64_UNWCODE_INFO (p[1]) == 1)
+		    {
+		      cache->prev_rip_addr = cur_sp + 8;
+		      cache->prev_rsp_addr = cur_sp + 32;
+		      cur_sp += 48;
+		    }
+		  else
+		    return;
+		  break;
+		default:
+		  return;
+		}
+	    }
+
+	  /* Adjust with the length of the opcode.  */
+	  switch (PEX64_UNWCODE_CODE (p[1]))
+	    {
+	    case UWOP_PUSH_NONVOL:
+	    case UWOP_ALLOC_SMALL:
+	    case UWOP_SET_FPREG:
+	    case UWOP_PUSH_MACHFRAME:
+	      break;
+	    case UWOP_ALLOC_LARGE:
+	      if (PEX64_UNWCODE_INFO (p[1]) == 0)
+		p += 2;
+	      else if (PEX64_UNWCODE_INFO (p[1]) == 1)
+		p += 4;
+	      else
+		return;
+	      break;
+	    case UWOP_SAVE_NONVOL:
+	    case UWOP_SAVE_XMM128:
+	      p += 2;
+	      break;
+	    case UWOP_SAVE_NONVOL_FAR:
+	    case UWOP_SAVE_XMM128_FAR:
+	      p += 4;
+	      break;
+	    default:
+	      return;
+	    }
+	}
+      if (PEX64_UWI_FLAGS (ex_ui.Version_Flags) != UNW_FLAG_CHAININFO)
+	break;
+      else
+	{
+	  /* Read the chained unwind info.  */
+	  struct external_pex64_runtime_function d;
+	  CORE_ADDR chain_vma;
+
+	  chain_vma = cache->image_base + unwind_info
+	    + sizeof (ex_ui) + ((codes_count + 1) & ~1) * 2 + 8;
+
+	  if (target_read_memory (chain_vma, (gdb_byte *) &d, sizeof (d)) != 0)
+	    return;
+
+	  cache->start_rva =
+	    extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order);
+	  cache->end_rva =
+	    extract_unsigned_integer (d.rva_EndAddress, 4, byte_order);
+	  unwind_info =
+	    extract_unsigned_integer (d.rva_UnwindData, 4, byte_order);
+	}
+
+      /* Allow the user to break this loop.  */
+      QUIT;
+    }
+  /* PC is saved by the call.  */
+  if (cache->prev_rip_addr == 0)
+    cache->prev_rip_addr = cur_sp;
+  cache->prev_sp = cur_sp + 8;
+
+  if (frame_debug)
+    fprintf_unfiltered (gdb_stdlog, "   prev_sp: %s, prev_pc @%s\n",
+			paddress (gdbarch, cache->prev_sp),
+			paddress (gdbarch, cache->prev_rip_addr));
+}
+
+/* Find SEH unwind info for PC, returning 0 on success.
+
+   UNWIND_INFO is set to the rva of unwind info address, IMAGE_BASE
+   to the base address of the corresponding image, and START_RVA
+   to the rva of the function containing PC.  */
+
+static int
+amd64_windows_find_unwind_info (struct gdbarch *gdbarch, CORE_ADDR pc,
+				CORE_ADDR *unwind_info,
+				CORE_ADDR *image_base,
+				CORE_ADDR *start_rva,
+				CORE_ADDR *end_rva)
+{
+  struct obj_section *sec;
+  pe_data_type *pe;
+  IMAGE_DATA_DIRECTORY *dir;
+  struct objfile *objfile;
+  unsigned long lo, hi;
+  CORE_ADDR base;
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+
+  /* Get the corresponding exception directory.  */
+  sec = find_pc_section (pc);
+  if (sec == NULL)
+    return -1;
+  objfile = sec->objfile;
+  pe = pe_data (sec->objfile->obfd);
+  dir = &pe->pe_opthdr.DataDirectory[PE_EXCEPTION_TABLE];
+
+  base = pe->pe_opthdr.ImageBase
+    + ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
+  *image_base = base;
+
+  /* Find the entry.
+
+     Note: This does not handle dynamically added entries (for JIT
+     engines).  For this, we would need to ask the kernel directly,
+     which means getting some info from the native layer.  For the
+     rest of the code, however, it's probably faster to search
+     the entry ourselves.  */
+  lo = 0;
+  hi = dir->Size / sizeof (struct external_pex64_runtime_function);
+  *unwind_info = 0;
+  while (lo <= hi)
+    {
+      unsigned long mid = lo + (hi - lo) / 2;
+      struct external_pex64_runtime_function d;
+      CORE_ADDR sa, ea;
+
+      if (target_read_memory (base + dir->VirtualAddress + mid * sizeof (d),
+			      (gdb_byte *) &d, sizeof (d)) != 0)
+	return -1;
+
+      sa = extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order);
+      ea = extract_unsigned_integer (d.rva_EndAddress, 4, byte_order);
+      if (pc < base + sa)
+	hi = mid - 1;
+      else if (pc >= base + ea)
+	lo = mid + 1;
+      else if (pc >= base + sa && pc < base + ea)
+	{
+	  /* Got it.  */
+	  *start_rva = sa;
+	  *end_rva = ea;
+	  *unwind_info =
+	    extract_unsigned_integer (d.rva_UnwindData, 4, byte_order);
+	  break;
+	}
+      else
+	break;
+    }
+
+  if (frame_debug)
+    fprintf_unfiltered
+      (gdb_stdlog,
+       "amd64_windows_find_unwind_data:  image_base=%s, unwind_data=%s\n",
+       paddress (gdbarch, base), paddress (gdbarch, *unwind_info));
+
+  if (*unwind_info & 1)
+    {
+      /* Unofficially documented unwind info redirection, when UNWIND_INFO
+	 address is odd (http://www.codemachine.com/article_x64deepdive.html).
+      */
+      struct external_pex64_runtime_function d;
+      CORE_ADDR sa, ea;
+
+      if (target_read_memory (base + (*unwind_info & ~1),
+			      (gdb_byte *) &d, sizeof (d)) != 0)
+	return -1;
+
+      *start_rva =
+	extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order);
+      *end_rva = extract_unsigned_integer (d.rva_EndAddress, 4, byte_order);
+      *unwind_info =
+	extract_unsigned_integer (d.rva_UnwindData, 4, byte_order);
+
+    }
+  return 0;
+}
+
+/* Fill THIS_CACHE using the native amd64-windows unwinding data
+   for THIS_FRAME.  */
+
+static struct amd64_windows_frame_cache *
+amd64_windows_frame_cache (struct frame_info *this_frame, void **this_cache)
+{
+  struct gdbarch *gdbarch = get_frame_arch (this_frame);
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+  struct amd64_windows_frame_cache *cache;
+  gdb_byte buf[8];
+  struct obj_section *sec;
+  pe_data_type *pe;
+  IMAGE_DATA_DIRECTORY *dir;
+  CORE_ADDR image_base;
+  CORE_ADDR pc;
+  struct objfile *objfile;
+  unsigned long lo, hi;
+  CORE_ADDR unwind_info = 0;
+
+  if (*this_cache)
+    return *this_cache;
+
+  cache = FRAME_OBSTACK_ZALLOC (struct amd64_windows_frame_cache);
+  *this_cache = cache;
+
+  /* Get current PC and SP.  */
+  pc = get_frame_pc (this_frame);
+  get_frame_register (this_frame, AMD64_RSP_REGNUM, buf);
+  cache->sp = extract_unsigned_integer (buf, 8, byte_order);
+  cache->pc = pc;
+
+  if (amd64_windows_find_unwind_info (gdbarch, pc, &unwind_info,
+				      &cache->image_base,
+				      &cache->start_rva,
+				      &cache->end_rva))
+    return cache;
+
+  if (unwind_info == 0)
+    {
+      /* Assume a leaf function.  */
+      cache->prev_sp = cache->sp + 8;
+      cache->prev_rip_addr = cache->sp;
+    }
+  else
+    {
+      /* Decode unwind insns to compute saved addresses.  */
+      amd64_windows_frame_decode_insns (this_frame, cache, unwind_info);
+    }
+  return cache;
+}
+
+/* Implement the "prev_register" method of struct frame_unwind
+   using the standard Windows x64 SEH info.  */
+
+static struct value *
+amd64_windows_frame_prev_register (struct frame_info *this_frame,
+				   void **this_cache, int regnum)
+{
+  struct gdbarch *gdbarch = get_frame_arch (this_frame);
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+  struct amd64_windows_frame_cache *cache =
+    amd64_windows_frame_cache (this_frame, this_cache);
+  struct value *val;
+  CORE_ADDR prev;
+
+  if (frame_debug)
+    fprintf_unfiltered (gdb_stdlog,
+			"amd64_windows_frame_prev_register %s for sp=%s\n",
+			gdbarch_register_name (gdbarch, regnum),
+			paddress (gdbarch, cache->prev_sp));
+
+  if (regnum >= AMD64_XMM0_REGNUM && regnum <= AMD64_XMM0_REGNUM + 15)
+      prev = cache->prev_xmm_addr[regnum - AMD64_XMM0_REGNUM];
+  else if (regnum == AMD64_RSP_REGNUM)
+    {
+      prev = cache->prev_rsp_addr;
+      if (prev == 0)
+	return frame_unwind_got_constant (this_frame, regnum, cache->prev_sp);
+    }
+  else if (regnum >= AMD64_RAX_REGNUM && regnum <= AMD64_R15_REGNUM)
+    prev = cache->prev_reg_addr[regnum - AMD64_RAX_REGNUM];
+  else if (regnum == AMD64_RIP_REGNUM)
+    prev = cache->prev_rip_addr;
+  else
+    prev = 0;
+
+  if (prev && frame_debug)
+    fprintf_unfiltered (gdb_stdlog, "  -> at %s\n", paddress (gdbarch, prev));
+
+  if (prev)
+    {
+      /* Register was saved.  */
+      return frame_unwind_got_memory (this_frame, regnum, prev);
+    }
+  else
+    {
+      /* Register is either volatile or not modified.  */
+      return frame_unwind_got_register (this_frame, regnum, regnum);
+    }
+}
+
+/* Implement the "this_id" method of struct frame_unwind using
+   the standard Windows x64 SEH info.  */
+
+static void
+amd64_windows_frame_this_id (struct frame_info *this_frame, void **this_cache,
+		   struct frame_id *this_id)
+{
+  struct gdbarch *gdbarch = get_frame_arch (this_frame);
+  struct amd64_windows_frame_cache *cache =
+    amd64_windows_frame_cache (this_frame, this_cache);
+
+  *this_id = frame_id_build (cache->prev_sp,
+			     cache->image_base + cache->start_rva);
+}
+
+/* Windows x64 SEH unwinder.  */
+
+static const struct frame_unwind amd64_windows_frame_unwind =
+{
+  NORMAL_FRAME,
+  default_frame_unwind_stop_reason,
+  &amd64_windows_frame_this_id,
+  &amd64_windows_frame_prev_register,
+  NULL,
+  default_frame_sniffer
+};
+
+/* Implement the "skip_prologue" gdbarch method.  */
+
+static CORE_ADDR
+amd64_windows_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
+{
+  CORE_ADDR func_addr;
+  CORE_ADDR unwind_info = 0;
+  CORE_ADDR image_base, start_rva, end_rva;
+  struct external_pex64_unwind_info ex_ui;
+
+  /* Use prologue size from unwind info.  */
+  if (amd64_windows_find_unwind_info (gdbarch, pc, &unwind_info,
+				      &image_base, &start_rva, &end_rva) == 0)
+    {
+      if (unwind_info == 0)
+	{
+	  /* Leaf function.  */
+	  return pc;
+	}
+      else if (target_read_memory (image_base + unwind_info,
+				   (gdb_byte *) &ex_ui, sizeof (ex_ui)) == 0
+	       && PEX64_UWI_VERSION (ex_ui.Version_Flags) == 1)
+	return max (pc, image_base + start_rva + ex_ui.SizeOfPrologue);
+    }
+
+  /* See if we can determine the end of the prologue via the symbol
+     table.  If so, then return either the PC, or the PC after
+     the prologue, whichever is greater.  */
+  if (find_pc_partial_function (pc, NULL, &func_addr, NULL))
+    {
+      CORE_ADDR post_prologue_pc
+	= skip_prologue_using_sal (gdbarch, func_addr);
+
+      if (post_prologue_pc != 0)
+	return max (pc, post_prologue_pc);
+    }
+
+  return pc;
+}
+
 /* Check Win64 DLL jmp trampolines and find jump destination.  */
 
 static CORE_ADDR
@@ -225,6 +977,9 @@
   set_gdbarch_iterate_over_objfiles_in_search_order
     (gdbarch, windows_iterate_over_objfiles_in_search_order);
 
+  frame_unwind_prepend_unwinder (gdbarch, &amd64_windows_frame_unwind);
+  set_gdbarch_skip_prologue (gdbarch, amd64_windows_skip_prologue);
+
   set_gdbarch_auto_wide_charset (gdbarch, amd64_windows_auto_wide_charset);
 
   set_solib_ops (gdbarch, &solib_target_so_ops);
@@ -239,4 +994,3 @@
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64, GDB_OSABI_CYGWIN,
                           amd64_windows_init_abi);
 }
-


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-08-22 11:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-19 15:14 [RFA] Windows x64 SEH unwinder (v2) Roland Schwingel
2013-08-19 15:32 ` Tristan Gingold
  -- strict thread matches above, loose matches on Subject: below --
2013-08-22 11:22 Roland Schwingel
2013-08-19 16:01 Roland Schwingel
2013-08-21 13:45 ` Tristan Gingold
2013-08-22 10:22   ` Pedro Alves
2013-08-05 11:25 Roland Schwingel
2013-08-19 13:53 ` Tristan Gingold
2013-01-09 10:53 Add Windows x64 SEH unwinder (take 2) Joel Brobecker
2013-01-09 10:53 ` [RFA/commit+doco 2/2] Windows x64 SEH unwinder Joel Brobecker
2013-01-09 15:52   ` Pedro Alves
2013-01-09 16:28     ` Tristan Gingold
2013-01-09 17:10       ` Pedro Alves
2013-01-09 20:07         ` Tristan Gingold
2013-01-10 16:24           ` Pedro Alves
2013-07-08 10:55             ` [RFA] Windows x64 SEH unwinder (v2) Tristan Gingold
2013-07-26 15:22               ` Pedro Alves
2013-08-19 13:59                 ` Tristan Gingold
2013-08-19 14:13                   ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox