This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Dumping of .pdata/.xdata for x64 PE+
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 16 Apr 2009 16:23:25 +0100
- Subject: Re: RFC: Dumping of .pdata/.xdata for x64 PE+
- References: <90baa01f0904140405i78236be7laf469196c10222bb@mail.gmail.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