This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Apr 16, 2009 at 10:04 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 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?
>

That is fine with me.

Thanks.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]