Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Thu, 16 Jan 2003 12:23:36 -0600 (CST) From: Brian Ford X-X-Sender: ford AT eos To: Nick Clifton cc: cygwin AT cygwin DOT com, , , Subject: HELP! How to add secrel psuedo op for pe-i386? Was Re: Support for DDWARF-2 debug info? (on Cygwin) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 executable. 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); > > #ifdef ASM_OUTPUT_DWARF_OFFSET > 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/