This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Dumping of .pdata/.xdata for x64 PE+
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