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

[Kai Tietz]

2009/4/16 H.J. Lu <hjl.tools@gmail.com>:
> On Thu, Apr 16, 2009 at 9:41 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2009/4/16 Dave Korn <dave.korn.cygwin@googlemail.com>:
>>> 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
>>>
>>
>> Hello HJ,
>>
>> as I read that you want to refactor EFI to use PEI. What is your
>> opinion about the place for the xdata dumping for x64?
>>
>
> Can you put it in pei-x86_64.c?
>
> --
> H.J.
>

Ok, put the complete code from peXXigen.c into pei-x86_64.c and make it static.

Is this ok for you and the refactoring?

Kai

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