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+


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?

Cheers,
Kai

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


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