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

["H.J. Lu" <hjl dot tools at gmail dot 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.