From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28127 invoked by alias); 9 Jan 2004 22:30:22 -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 28088 invoked from network); 9 Jan 2004 22:30:16 -0000 Received: from unknown (HELO motgate8.mot.com) (129.188.136.8) by sources.redhat.com with SMTP; 9 Jan 2004 22:30:16 -0000 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i09MUFDc002216 for ; Fri, 9 Jan 2004 15:30:15 -0700 (MST) Received: from udc.urbana.css.mot.com (udc.urbana.css.mot.com [192.88.153.21]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i09MUCiN006624 for ; Fri, 9 Jan 2004 16:30:12 -0600 Received: from tmclinux.urbana.css.mot.com (tmclinux.urbana.css.mot.com [192.88.153.36]) by udc.urbana.css.mot.com (8.11.7p1+Sun/8.11.6) with ESMTP id i09MUB024673; Fri, 9 Jan 2004 16:30:11 -0600 (CST) X-POPI: The contents of this message are Motorola Internal Use Only (MIUO) unless indicated otherwise in the message. Received: (from tcombs@localhost) by tmclinux.urbana.css.mot.com (8.11.6/8.11.6) id i09MUBK26164; Fri, 9 Jan 2004 16:30:11 -0600 Date: Fri, 09 Jan 2004 22:30:00 -0000 From: Tim Combs To: Michael Eager Cc: Jim Blandy , anocean@aromasoft.com, gdb@sources.redhat.com Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? Message-ID: <20040109163011.G25255@urbana.css.mot.com> References: <000701c3d4ec$f8c1d9d0$0e01a8c0@bathory> <3FFEE1F0.7020408@eagercon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FFEE1F0.7020408@eagercon.com>; from eager@eagercon.com on Fri, Jan 09, 2004 at 09:16:32AM -0800 X-SW-Source: 2004-01/txt/msg00129.txt.bz2 When I talked to Arm support about the 1.0.1 they mentioned that the next compiler would have better GDB support. It did because they fixed a few bugs in their DWARF generation. They recommended going to a later compiler because their DWARF2 generation is much better. It is but it has the same design. It generates a compile unit for each header file in the file. This makes referent die support necessary for the Arm ADS compiler. Tim On Fri, Jan 09, 2004 at 09:16:32AM -0800, Michael Eager wrote: > Jim Blandy wrote: > > "Jang, Jaewoo" writes: > > > >>I try to debug elf dwarf2 format whcih is generated by ADS 1.0.1 compiler. > >>It seems that gdb support dwarf2 spec. > >>But ARM dwarf2 spec is somehow modified from drawf2 spec. > >>This is the reference of ARM dwar2 spec. > >>http://www.linuxbase.org/spec/refspecs/dwarf/ARMDwarf2.pdf > >> > >>I want to know whether gdb will support ARM dwarf2 format, > >>or it is possible to patch gdb that support ARM dwarf format. > >>Now I try to understand source codes that is part of reading elf format. > >>It is hard to understand. :( > > > > > > The differences described in section 4 of that document sound like > > pretty serious divergences from the Dwarf 2 spec. ARM Dwarf 2 creates > > multiple .debug_info sections, one for each source file, with names > > suffixed by the source file name. This affects the way name lookup is > > performed: > > > > This organisation makes the debugger's job in performing name lookup > > more complex. With a single debug table per object it need merely > > identify the place within the single table describing the function > > definition containing the current pc, and work backward and outward > > through the nested scopes described by the table. In the ARM DWARF2 > > organisation, it needs to do that first, but then needs to look > > through the tables for files containing the function definition or > > included from those files, and the other debug sections describing > > sections generated from those files. This is possible because: > > > > - the .debug_line table in the set of tables describing a file > > contains both the name of the file and the names of the files it > > directly includes > > > > - the .debug_line table in the set of tables describing a code or data > > section contains the name of all files defining entities included in > > the section. > > > > The order of declarations and definitions can be reconstructed, since > > source position information is present for all definitions and > > declarations, and also the source position of #include directives is > > described in macro information tables. > > > > GDB certainly can't read Dwarf 2 information arranged in this way at > > the moment. > > It wasn't clear to me from skiming their document that they were > generating multiple .debug_info sections, but now I see that this is > described in terms of generating "table_name$$$file_name", where, I > assume, table_name is .debug_info or other predefined name. > > That really does make it a different file format, requiring different > processing. > > > -- > Michael Eager Eager Consulting eager@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 >