From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20880 invoked by alias); 8 Jan 2004 23:46:31 -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 20872 invoked from network); 8 Jan 2004 23:46:30 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 8 Jan 2004 23:46:30 -0000 Received: by zenia.home (Postfix, from userid 5433) id E143D207CC; Thu, 8 Jan 2004 18:40:20 -0500 (EST) To: Cc: Subject: Re: gdb supports dwarf2 which is generated by ADS compiler? References: <000701c3d4ec$f8c1d9d0$0e01a8c0@bathory> From: Jim Blandy Date: Thu, 08 Jan 2004 23:46:00 -0000 In-Reply-To: <000701c3d4ec$f8c1d9d0$0e01a8c0@bathory> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg00109.txt.bz2 "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.