Re: Stack traces and sections in PE/COFF

[Joe Abbey <joe dot abbey at gmail dot com>]

For documentation on the PE/COFF specification please see:

http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

In Section 4.0, you'll find that these are long name offsets into the
string table, as the name field of the Section Table is described as
follows:

"An 8-byte, null-padded UTF-8 encoded string. If the string is exactly
8 characters long, there is no terminating null. For longer names,
this field contains a slash (/) that is followed by an ASCII
representation of a decimal number that is an offset into the string
table. Executable images do not use a string table and do not support
section names longer than 8 characters. Long names in object files are
truncated if they are emitted to an executable file."

I can't speak on behalf of what BFD does, but this should at least
help you understand what the fields are.

Cheers,

Joe

On Mon, Feb 2, 2009 at 1:03 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
>
> 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