Re: RFC: Dumping of .pdata/.xdata for x64 PE+

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

  Before we begin: I found some more links.

The paper "Improving Automated Analysis of Windows x64 Binaries" by Skape in
uninformed (reverse engineering) journal, is at:

  http://uninformed.org/?v=4&a=1&t=pdf
(plaintext version) http://www.uninformed.org/?v=4&a=1&t=txt

and a Matt Pietrek "Under the Hood" article "Everything You Need To Know To
Start Programming 64-Bit Windows Systems" can be found at:

 http://msdn.microsoft.com/en-gb/magazine/cc300794.aspx

and from there a link to Kevin Frei's blog post "X64 Unwind Information":

  http://blogs.msdn.com/freik/archive/2006/01/04/509372.aspx

also a few other posts from the same blog:

http://blogs.msdn.com/freik/archive/2007/03/12/amd64-unwind-info-gotchas.aspx
http://blogs.msdn.com/freik/archive/2006/03/06/X64-calling-conventions-summary.aspx
http://blogs.msdn.com/freik/archive/2007/03/15/how-to-use-rtlunwindex.aspx

  On with the code!

Kai Tietz wrote:

> I want to implement for binutils and gcc's 4.5 version the handling of
> SEH for x64 windows PE format. So I implemented a dumping mechanism of
> the .xdata structures for this OS. This patch isn't intended to be
> approved as it is, it is more a request to review and discussion about
> this subject. I would be happy if some people could comment on it.

  I like this change:

Index: src/bfd/coff-x86_64.c
===================================================================
--- src.orig/bfd/coff-x86_64.c
+++ src/bfd/coff-x86_64.c
@@ -711,14 +711,9 @@ coff_amd64_is_local_label_name (bfd *abf

 #endif /* TARGET_UNDERSCORE */

-#ifdef PE
-#undef  bfd_pe_print_pdata
-#define bfd_pe_print_pdata   _bfd_pex64_print_pdata
-#else  /* PE */
 #ifndef bfd_pe_print_pdata
 #define bfd_pe_print_pdata   NULL
 #endif
-#endif /* PE */


  I'm not so keen on this one:

Index: src/bfd/peXXigen.c
===================================================================
--- src.orig/bfd/peXXigen.c
+++ src/bfd/peXXigen.c
@@ -1897,6 +1897,327 @@ _bfd_XX_print_ce_compressed_pdata (bfd *

 #ifdef COFF_WITH_pex64
 /* The PE+ x64 variant.  */
+


  My main comment is this: the code does not belong in peXXigen.c, because the
purpose of that file is to provide "template" code that can be autogenerated
into all (or at any rate, multiple) PE targets, and this code is only for one
target and does not include "XX" in the function name.

  Although it's not used a lot, there is at least precedent (bfd/pe-mips.c)
for putting such format-and-arch specific functions into the master back-end
file.  How would you feel about putting this function into bfd/pei-x86_64.c?

Index: src/bfd/pei-x86_64.c
===================================================================
--- src.orig/bfd/pei-x86_64.c
+++ src/bfd/pei-x86_64.c
@@ -25,9 +25,9 @@

 #define TARGET_SYM 		x86_64pei_vec
 #define TARGET_NAME 		"pei-x86-64"
-#define COFF_IMAGE_WITH_PE
 #define COFF_WITH_PE
 #define COFF_WITH_pex64
+#define COFF_IMAGE_WITH_PE
 #define PCRELOFFSET 		TRUE

  That change is not really necessary :)

> The biggest question for me (at the moment) are the language specific
> termination handlers (flag 3). The data related to this entry kind
> seems to be the establisher frame pointer. 

  One of us is confused, and it's more likely me since I've only just started
looking at this, but... are you talking about UNW_FLAG_EHANDLER and
UNW_FLAG_UHANDLER?  These are bits from the UNWIND_INFO.Flags field, and if
you set both of them the result is 0x1 | 0x2 == 0x3.  3 is also the value of
the UWOP_SET_FPREG unwind code op, but it's not related.  The exception
handler functions come in an extra entry after the end of the array of unwind
codes - see section 4.1.3 in the uninformed.org article.

> Also there are some unclear
> points about the UnwindCode about ...LARGE elements. At top of MS
> documentation the tell, that any element is scaled 8 (beside the XMM
> ones, they are scaled 16), but in further documentation the tell that
> the ...LARGE variant are describing it unscaled.

  I believe the section talking about scaling applies only to the offsets
pointing to stack slots within the frames, and this quantity is a size rather
than an offset.  The explanation at

http://msdn.microsoft.com/en-us/library/ck9asaa9(VS.80).aspx

seems clear to me:

"UWOP_ALLOC_LARGE (1) 2 or 3 nodes

Allocate a large-sized area on the stack. There are two forms. If the
operation info equals 0, then the size of the allocation divided by 8 is
recorded in the next slot, allowing an allocation up to 512K – 8. If the
operation info equals 1, then the unscaled size of the allocation is recorded
in the next two slots in little-endian format, allowing allocations up to 4GB
– 8. "

  So it exists in both a scaled-by-8 and an unscaled variant.

    cheers,
      DaveK