Re: Non-zero VMA's w/DWARF-2?

Re: Non-zero VMA's w/DWARF-2?

[Brian Ford]

DJGPP does not have the constraints of a PE/COFF object file format.  As I
understand it, they have a wrapper that loads COFF, so they can do as they
please.

I have already done everything that DJGPP does, but I can not make the
vma's of the .debug_* sections zero without violating the PE/COFF format
and rendering the executable useless.

Thus, I need a DWARF-2 expert to tell me how to modify the code to work
with non-zero VMA's.

Thanks for trying, though.

On Thu, 16 Jan 2003, Dave Hooper wrote:

> I've been informed (though maybe erroneously?) that djgpp supports DWARF-2
> so maybe that would be a resonable starting point for investigation?
>
> > From: "Brian Ford" <ford@vss.fsi.com>
> > I am trying to add DWARF-2 support to Cygwin.
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: Non-zero VMA's w/DWARF-2?

[Eli Zaretskii]

> Date: Wed, 15 Jan 2003 18:24:27 -0600 (CST)
> From: Brian Ford <ford@vss.fsi.com>
> 
> DJGPP does not have the constraints of a PE/COFF object file format.  As I
> understand it, they have a wrapper that loads COFF, so they can do as they
> please.

That's true: a DJGPP program has a short 2KB stub loader prepended to
it.  To the OS, that stub is the program; the COFF image is just data
which the OS knows nothing about.  When the stub is invoked, it reads
the COFF information from the rest of the .exe file, sets up memory as
required by the sections in the image, then jumps to the start point
of the COFF image.

Non-zero VMA's w/DWARF-2?

[Brian Ford]

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