On Wed, May 27, 2015 at 6:36 AM, Jeff Law <l...@redhat.com> wrote:
> On 05/21/2015 06:41 AM, Tristan Gingold wrote:
>>
>> Hello,
>>
>> this patch adds basic support to libbacktrace for PE32 and PE32+ (Windows
>> and Windows64 object formats).
>> Support is ‘basic’ because neither DLL nor PIE (if that exists) are
>> handled. Furthermore, there is no windows versions of mmapio.c and mmap.c
>> Finally, I have disabled the support of data symbols for PE because I
>> wasn’t able to pass ‘make check’ with that: symbol ‘_global’ is at the same
>> address as a symbol defined by the linker and I haven’t found any way to
>> discard the latter. As I think data symbol support isn’t a required
>> feature, I have preferred to disable that feature on PE.
>>
>> The new file, pecoff.c, mostly follows the structure of elf.c
>>
>> Tested on both windows and windows64.
>> No regression on Gnu/Linux x86.
>>
>> Tristan.
>>
>>
>> 2015-05-21 Tristan Gingold <ging...@adacore.com>
>>
>> * pecoff.c: New file.
>> * Makefile.am (FORMAT_FILES): Add pecoff.c and dependencies.
>> * Makefile.in: Regenerate.
>> * filetype.awk: Detect pecoff.
>> * configure.ac: Define BACKTRACE_SUPPORTS_DATA on elf platforms.
>> Add pecoff.
>> * btest.c (test5): Test enabled only if BACKTRACE_SUPPORTS_DATA is
>> true.
>> * backtrace-supported.h.in (BACKTRACE_SUPPORTS_DATA): Define.
>> * configure: Regenerate.
>> * pecoff.c: New file.
>> +
>> +/* Return true iff SYM is a defined symbol for a function. Data symbols
>> + are discarded because they aren't easily identified. */
>> +
>> +static int
>> +coff_is_symbol (const b_coff_internal_symbol *isym)
>> +{
>> + return isym->type == 0x20 && isym->sec > 0;
>> +}
>
> You probably want const or enum so that you can have a symbolic name rather
> than 0x20 here. It also seems like the name ought to better indicate it's
> testing for function symbols.
>
> It's a given that you know COFF specifics better than I ever did, so I'm
> comfortable assuming you got the COFF specifics right.
>
> The overall structure of elf.c & coff.c is the same with code templates that
> are very similar, except they work on different underlying types.
> Presumably there wasn't a good way to factor any of the generic looking bits
> out? And no, I'm not requesting you rewrite all this in BFD :-)
>
>
> OK for the trunk. Any future issues with the coff bits I'll send your way.
The #include <windows.h> will break cross-compilers. It's not OK for
trunk until that is fixed.
Ian
