From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9774 invoked by alias); 21 Feb 2003 16:16:53 -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 9750 invoked from network); 21 Feb 2003 16:16:52 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by 172.16.49.205 with SMTP; 21 Feb 2003 16:16:52 -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 KAA07550 for ; Fri, 21 Feb 2003 10:16:51 -0600 (CST) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.11.6+Sun/8.11.6) with ESMTP id h1LGGnW25421 for ; Fri, 21 Feb 2003 10:16:50 -0600 (CST) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Fri, 21 Feb 2003 16:16:00 -0000 From: Brian Ford X-X-Sender: ford@eos To: gdb@sources.redhat.com Subject: DWARF 2 sections and padding ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-02/txt/msg00464.txt.bz2 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. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444