From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14412 invoked by alias); 21 Feb 2003 18:59:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14385 invoked from network); 21 Feb 2003 18:59:56 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by 172.16.49.205 with SMTP; 21 Feb 2003 18:59:56 -0000 Received: from eos.vss.fsi.com (eos [198.51.27.61]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id MAA12652; Fri, 21 Feb 2003 12:59:55 -0600 (CST) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.11.6+Sun/8.11.6) with ESMTP id h1LIxsi14721; Fri, 21 Feb 2003 12:59:55 -0600 (CST) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Fri, 21 Feb 2003 18:59:00 -0000 From: Brian Ford X-X-Sender: ford@eos To: binutils@sources.redhat.com cc: gdb@sources.redhat.com Subject: Re: DWARF 2 sections and padding ? In-Reply-To: <20030221171627.GA15165@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-02/txt/msg00476.txt.bz2 On Fri, 21 Feb 2003, Daniel Jacobowitz wrote: > On Fri, Feb 21, 2003 at 10:16:49AM -0600, Brian Ford wrote: > > I am trying to add DWARF 2 support for PE/COFF on Cygwin. PE/COFF > > sections must be aligned to 512 byte boundaries. This extra padding > > confuses the DWARF 2 parsing routines because they use the sections > > raw_size, thus parsing an invalid compilation unit header (all > > zeros). > > > > The actual, smaller size is available in the section header. I am > > confused about what the cooked_size is supposed to mean. It is currently > > zero, but I think it could contain the smaller virtual size. > > > > I have read the DWARF spec several times, and although it discusses this > > issue briefly for some debugging sections, it is unclear to me how this > > should really work. Unless I try to arrange for the producer (gcc) to > > pad the compilation units with zeros instead of having bfd pad the end of > > the sections, I don't know how to proceed. > > > > I would like to just use an alternate size instead of the raw size (cooked > > maybe?) but I don't know how this would affect other targets and I don't > > want a PE specific hack in DWARF parsing code. > > > > Any ideas? Thanks. > > I don't see why the raw size should include the padding; that should > just be used when _placing_ sections. But this is a binutils/bfd > issue; redirected to that list. > The raw size appears to translate directly to the size in the section header. The PE/COFF format states this must be a multiple of the page size. Other COFF targets that define ALIGN_SECTIONS_IN_FILE do the same thing, in separate code, though. There is one case where these other targets do what you suggest, if COFF_PAGE_SIZE is defined: /* In demand paged files the low order bits of the file offset must match the low order bits of the virtual address. */ #ifdef COFF_PAGE_SIZE if ((abfd->flags & D_PAGED) != 0 && (current->flags & SEC_ALLOC) != 0) sofar += (current->vma - sofar) % page_size; #endif I modified the PE/COFF code to do this instead and, although it violates the format, a simple test appeared valid and runable on Windows XP. What do the binutils maintainers think about making this change? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444