From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7484 invoked by alias); 9 Dec 2004 16:59:35 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 7456 invoked from network); 9 Dec 2004 16:59:29 -0000 Received: from unknown (HELO relay0.EECS.Berkeley.EDU) (169.229.60.163) by sourceware.org with SMTP; 9 Dec 2004 16:59:29 -0000 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id iB9GxO0Z008857; Thu, 9 Dec 2004 08:59:24 -0800 (PST) Received: from [128.32.33.73] (dhcp-33-73.EECS.Berkeley.EDU [128.32.33.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I8G00D9ZSIZSN@gateway2.EECS.Berkeley.EDU>; Thu, 09 Dec 2004 08:59:24 -0800 (PST) Date: Thu, 09 Dec 2004 16:59:00 -0000 From: Allen Hopkins Subject: Re: Bogus DWARF line#/address In-reply-to: <6.2.0.14.2.20041209085645.0215b6d0@iplan-mn.corp.adobe.com> To: Eljay Love-Jensen Cc: gcc-help@gcc.gnu.org Message-id: <41B8846B.3000805@eecs.berkeley.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 References: <41B7906E.2060301@eecs.berkeley.edu> <6.2.0.14.2.20041209085645.0215b6d0@iplan-mn.corp.adobe.com> X-SW-Source: 2004-12/txt/msg00083.txt.bz2 No, no optimization options. Just -ggdb, -Wno-deprecated. I understand the "-O0" (oh-zero) is the same as no -O at all. But I'll try it. I'm pretty desparate for ideas. -Allen Eljay Love-Jensen wrote: > Hi Allen, > > Was the code compiled with -O0? > > --Eljay > > > I'm trying to use gdb to debug code compiled with g++ > > (3.4.3) from .cpp source files that have, in turn, been > > compiled from higher-level source code by a special > > compiler we're developing here called Metropolis. > > > > Metropolis source files have .mmm extensions, and there is > > a .cpp file generated for each one. #line directives are > > inserted in the .cpp files so gdb can display the .mmm > > source, and breakpoints can be set in terms of lines in the > > .mmm files. > > > > The problem: Sometimes setting a breakpoint at a .mmm file > > line results in a breakpoint at an absurd place, unrelated > > to the desired line. > > > > I ran "readelf -wl" on the executable to see what addresses > > are being associated with what lines of code in the DWARF-2 > > output. The results are interesting: > > > > readelf shows that line 42 of P.mmm, where I want to set my > > breakpoint & can't, first gets one address associated > > with it (the wrong one, where my breakpoint really ends up). > > Then, further down in the output, it shows it getting the > > right one. (The wrong one is the address of the destructor > > of some class in the application.) > > > > I've posted the relevant files here, at > > http://www.eecs.berkeley.edu/~allenh/bogus_dwarf. > > READ_ME.txt tells what to look for & where. > > > > Any help or suggestions with this would be greatly > > appreciated. I don't understand how g++ works enough to > > make sense of it. > > > > g++ is version 3.4.3 > > uname -a says: > > Linux hig.eecs.berkeley.edu 2.6.7-1.494.2.2smp #1 SMP Tue Aug 3 09:59:49 EDT 2004 i686 i686 i386 GNU/Linux > > > > -Allen Hopkins