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

Dave Korn dave.korn.cygwin@googlemail.com
Thu Apr 16 16:28:00 GMT 2009


Kai Tietz wrote:
> 2009/4/16 Dave Korn <dave.korn.cygwin@googlemail.com>:

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

  Hey, you should talk to HJ; he's planning to refactor EFI to use PEI
vectors[*].  Yes, if this function can be used directly (or more-or-less)
directly for EFI formats too, then it should have an XX in the name and go
into peXXigen.c, that would be fine.

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

  Sorry, I trimmed that bit; it was present in your patch but I had no comment
to make about it since it is obviously correct!

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

  Ah, so in terms of the description at
http://msdn.microsoft.com/en-us/library/ddssxxy8(VS.80).aspx:

---------------------------------<snip>---------------------------------
(1) Exception Handler

ULONG		Address of exception handler
variable	Language-specific handler data (optional)

 Address of exception handler

    This is an image-relative pointer to either the function's
language-specific exception/termination handler (if flag UNW_FLAG_CHAININFO is
clear and one of the flags UNW_FLAG_EHANDLER or UNW_FLAG_UHANDLER is set).

Language-specific handler data

    This is the function's language-specific exception handler data. The
format of this data is unspecified and completely determined by the specific
exception handler in use.
---------------------------------<snip>---------------------------------

... you've got the function pointer OK, and you want to know about the
language-specific data?  I would imagine that the establisher frame is
computed by the unwinder using the prolog unwind codes, and so does not need
to be present in the language-specific data; the most obvious thing I can
think of is that this language-specific data ought to in some fashion point to
some information that tells what kind of exceptions to catch, e.g. in C++,
where the runtime is using SEH to catch C++ exception types, I would suppose
the exception handler pointer points to a function in MSVC that's the
modern-day equivalent of except_handler3, and the language-specific data would
point in some fashion to a list of the exception types for which catch(){...}
blocks exist.  I imagine we'll have to do some fancy reverse engineering to
figure it all out.

    cheers,
      DaveK
-- 
[*] - http://sourceware.org/ml/binutils/2009-04/msg00230.html



More information about the Binutils mailing list