HELP! How to add secrel psuedo op for pe-i386? Was Re: Support for DDWARF-2 debug info? (on Cygwin)

Brian Ford
Thu Jan 16 18:24:00 GMT 2003

On Thu, 16 Jan 2003, Brian Ford wrote:

> So, all I need to do is define ASM_OUTPUT_DWARF_OFFSET correctly in
> gcc/config/i386/cygwin.h.
> Does anyone have a good way to define a section relative offset in
> assembly for Cygwin, or do I need to define labels for the sections in the
> link script and use them?  That seems messy.
I think the "correct" way to handle this is to implement the secrel psuedo
op like IA64 does.  I only have a very vauge idea what this means.

Can a binutils guru enlighten me on what's involved here?  Thanks.

More below if your interested.

> On 16 Jan 2003, Nick Clifton wrote:
> > Hi Brian,
> >
> > > My current problem is that all previous DWARF2 implementations
> > > assign a VMA of zero to the .debug_* sections in the link script.
> > > This violates the PE format and makes the executable unusable.
> >
> > I saw your post about this to the binutils list.
> >
> > Does the PE format require that the debugging sections be loaded into
> > memory when the executable is invoked ?  The reason that the ELF
> > format allows the .debug sections to have a VMA of zero is that they
> > also do not have the ALLOC flag, so they are not loaded into memory.
> > (A debugger wanting to access the sections for a running process must
> > locate the executable on disk an load them/mmap them from there).
> >
> No, they do not need to be loaded into memory, and they do not have the
> ALLOC flag set.  But, the PE format requires all sections to be adjacent
> and in ascending order of VMA.  It also specifies debug sections should be
> last.  I think it just tries to load everything up to the fist non-ALLOC
> section, or so it seams.
After further reading, the PE format may load all sections, I just can't
tell.  But I know putting one at a VMA of 0, even if it is not marked
ALLOC or LOAD, and it is marked NEVER_LOAD and EXCLUDE, will break the

From: "Microsoft Portable Executable and Common Object File Format
Specification 6.0"

6.1.1. Debug Directory (Image Only)

Each debug directory entry identifies the location and size of a block of
debug information. The RVA specified may be 0 if the debug information is
not covered by a section header (i.e., it resides in the image file and is
not mapped into the run-time address space). If it is mapped, the RVA is
its address.

> > > I am still consulting the DWARF2 spec to see if gcc and gas are
> > > correct in generating VMA addresses.  If so, I guess I have to fix
> > > the dwarf parsing code in bfd and gdb to subtract the section base
> > > VMA.
> >
> > I do not believe that the DWARF2 spec mandates the VMA addresses of
> > the .debug sections.  It does say that their contents must be
> > contiguous, and it does specify the meaning of their contents, but it
> > does not specify the meaning of partially-complete .debug sections.
> > (ie ones attached to relocations that have not yet been resolved).
> >
> No, it does not, but I did find out it mandates section relative offsets.
> So, the dwarf parsing code is correct.  It is gcc that has taken a
> short cut.  BTW, these problems are with fully linked executables.
> From gcc/dwarf2asm.c:122
> /* Output a section-relative reference to a label.  In general this
>    can only be done for debugging symbols.  E.g. on most targets with
>    the GNU linker, this is accomplished with a direct reference and
>    the knowledge that the debugging section will be placed at VMA 0.
>    Some targets have special relocations for this that we must use.  */
> void
> dw2_asm_output_offset VPARAMS ((int size, const char *label,
>                                const char *comment, ...))
> {
>   VA_OPEN (ap, comment);
>   VA_FIXEDARG (ap, int, size);
>   VA_FIXEDARG (ap, const char *, label);
>   VA_FIXEDARG (ap, const char *, comment);
>   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, size, label);
> #else
>   dw2_assemble_integer (size, gen_rtx_SYMBOL_REF (Pmode, label));
> #endif
> [snip above]
> > So, I think it is the case that BFD and GDB are both assuming that the
> > VMA of the sections will be zero, but that this is not required.
> >
> Actually, as stated above, bfd and gdb are correct.  The VMA should not
> be relevant as section relative offsets are specified.

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

More information about the Binutils mailing list