HELP! How to add secrel psuedo op for pe-i386? Was Re: Support for DDWARF-2 debug info? (on Cygwin)
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
> 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
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
> > > 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. */
> 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);
> #ifdef ASM_OUTPUT_DWARF_OFFSET
> ASM_OUTPUT_DWARF_OFFSET (asm_out_file, size, label);
> dw2_assemble_integer (size, gen_rtx_SYMBOL_REF (Pmode, label));
> [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.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
More information about the Binutils