From: Brian Ford <ford@vss.fsi.com>
To: binutils@sources.redhat.com, <gdb@sources.redhat.com>,
<cygwin@cygwin.com>
Subject: Non-zero VMA's w/DWARF-2?
Date: Wed, 15 Jan 2003 19:47:00 -0000 [thread overview]
Message-ID: <Pine.GSO.4.44.0301151337580.12926-100000@eos> (raw)
I am trying to add DWARF-2 support to Cygwin.
I have run into the problem that all example DWARF-2 implementations seem
to expect the .debug_* sections' VMAs to be zero. This contradicts the
PE/coff object format as I read it, and the resulting executable will not
run.
From "Microsoft Portable Executable and Common Object File Format
Specification 6.0":
4.) Section Table (Section Headers)
In an image file, the virtual addresses for sections must be assigned by
the linker such that they are in ascending order and adjacent, and they
must be a multiple of the Section Align value in the optional header.
and
5. Other Contents of the File
The remainder of a COFF object or image file contains blocks of data that
are not necessarily at any specific file offset. Instead the locations are
defined by pointers in the Optional Header or a section header.
[...]
Another exception is that attribute certificate and debug information
must be placed at the very end of an image file (with the attribute
certificate table immediately preceding the debug section), because the
loader does not map these into memory. The rule on attribute certificate
and debug information does not apply to object files, however.
Am I reading this wrong? Who's the PE expert? Is there any hope of
non-zero VMAs for .debug_* sections?
Thanks.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
next reply other threads:[~2003-01-15 19:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-15 19:47 Brian Ford [this message]
2003-01-16 0:24 Brian Ford
2003-01-16 16:19 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.44.0301151337580.12926-100000@eos \
--to=ford@vss.fsi.com \
--cc=binutils@sources.redhat.com \
--cc=cygwin@cygwin.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox