From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6749 invoked by alias); 9 Jan 2004 17:16:50 -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 6698 invoked from network); 9 Jan 2004 17:16:38 -0000 Received: from unknown (HELO shell4.bayarea.net) (209.128.82.1) by sources.redhat.com with SMTP; 9 Jan 2004 17:16:38 -0000 Received: from eagercon.com (209-128-106-254.bayarea.net [209.128.106.254]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i09HGW203351; Fri, 9 Jan 2004 09:16:32 -0800 Message-ID: <3FFEE1F0.7020408@eagercon.com> Date: Fri, 09 Jan 2004 17:16:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: Jim Blandy CC: anocean@aromasoft.com, gdb@sources.redhat.com Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? References: <000701c3d4ec$f8c1d9d0$0e01a8c0@bathory> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00126.txt.bz2 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