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

[Kai Tietz <ktietz70 at googlemail dot com>]

2009/4/16 Dave Korn <dave.korn.cygwin@googlemail.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

Thanks for the links. I'll take a look into them. Possibly I can find
some hints about the pieces missing.

> ?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:

Yeah, it makes no sense to introduce here a new define.

> 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?

Well, in general the implementation could be in pei-x86_64.c file. I
am just not sure if the EFI versions possible want to use this, too.
If so, it has to be at in common file.

> 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 :)
Ups, I missed to update the patch. Of course it is not necessary ;)
Instead the macro #define bfd_pe_print_pdata   _bfd_pex64_print_pdata
has to be added.

>> 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.

I meant the flag value in UNWIND_INFO. It appears to exists value 3
for it (UNW_FLAG_EHANDLER|UNW_FLAG_UHANDLER). And the corresponding
data (after the array of unwind codes) is different. It contains a
frame pointer (relative to frame offset+frameRegister) AFAIU. I was
asking if somebody has an idea what the pointer points to on stack. I
assume it is an object pointer, or the establisher frame itself.

>> 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.
Yes, this is my understanding, too. I wanted just to cross check this.

> ? ?cheers,
> ? ? ?DaveK
>
>

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination