From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8491 invoked by alias); 21 Feb 2003 17:16:37 -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 8478 invoked from network); 21 Feb 2003 17:16:37 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 21 Feb 2003 17:16:37 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18mIfy-0003n4-00; Fri, 21 Feb 2003 13:17:39 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18mGmh-0003xl-00; Fri, 21 Feb 2003 12:16:27 -0500 Date: Fri, 21 Feb 2003 17:16:00 -0000 From: Daniel Jacobowitz To: Brian Ford Cc: gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: DWARF 2 sections and padding ? Message-ID: <20030221171627.GA15165@nevyn.them.org> Reply-To: binutils@sources.redhat.com Mail-Followup-To: Brian Ford , gdb@sources.redhat.com, binutils@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00469.txt.bz2 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer