Re: Stack traces and sections in PE/COFF

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Piotr Wyderski wrote:

  Hi Piotr.  I've redirected this thread to the binutils mailing list,
because the problems is almost certainly at the assembler or linker end of the
toolchain rather than with the compiler.

> I've already implemented a stack walker, but there is an open problem with
> symbol name/line lookup. The compiler (GCC 4.4-trunk) emits DWARF2-compatible
> debug information, but I don't know how to reach the appropriate
> sections (especially
> ".debug_info") within the executable. The PE header walker is able to
> dump PE sections,
> but they have strange, numeric names, e.g.:
>
> sec[0]: name = .text
> sec[1]: name = .data
> sec[2]: name = .rdata
> sec[3]: name = .bss
> sec[4]: name = .idata
> sec[5]: name = /4
> sec[6]: name = /19
> sec[7]: name = /35
> sec[8]: name = /47
> sec[9]: name = /61
> sec[10]: name = /73
> sec[11]: name = /86
> sec[12]: name = /97
> sec[13]: name = /108
>
> On the other hand, the DWARF sections are available in the file -- a hexdump
> viewer can locate them, as well as objdump. Could somebody please tell me
> what should I do in order to get to the DWARF sections from this point?
> Any documentation will be appreciated.

  Well, I can reproduce this problem, apparently: objdump gives me sensible
results, but running PEview shows silly names in the IMAGE_SECTION_HEADERs
(and sometimes even crashes).  I'll take a look at what's going on; this is
most likely a binutils problem, it may be generating a file format that isn't
quite compliant with the PE standard.  It's also possible that binutils is
generating something that is technically valid according to the standard, but
isn't the usual way of doing things and some software that makes the
assumption that how files are laid out by the standard MS tools is the only
way, rather than just one of many ways permitted way according to the spec.

  (Presumably you aren't using BFD to read the executable, or it should be
working the same as objdump.)

    cheers,
      DaveK