From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23330 invoked by alias); 14 Sep 2002 11:49:19 -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 23317 invoked from network); 14 Sep 2002 11:49:18 -0000 Received: from unknown (HELO imag.imag.fr) (129.88.30.1) by sources.redhat.com with SMTP; 14 Sep 2002 11:49:18 -0000 Received: from horus.imag.fr (horus.imag.fr [129.88.38.1]) by imag.imag.fr (8.11.6/8.11.6) with ESMTP id g8EBnAa08623; Sat, 14 Sep 2002 13:49:10 +0200 (MEST) Received: from imag.fr (conque.imag.fr [129.88.38.148]) by horus.imag.fr (8.11.6/8.11.6/Imag.pm.V2) with ESMTP id g8EBn9W17087; Sat, 14 Sep 2002 13:49:09 +0200 (MEST) Message-ID: <3D832247.D1F4ECBC@imag.fr> Date: Sat, 14 Sep 2002 04:49:00 -0000 From: Pierre Habraken Organization: =?iso-8859-1?Q?Universit=E9?= Joseph Fourier X-Accept-Language: en MIME-Version: 1.0 To: binutils@sources.redhat.com, gdb@sources.redhat.com CC: "Keith.Walker" , Elias Athanasopoulos Subject: Re: Section .debug_info in object file References: <4.1.20020912105556.01e79f10@mhsun1.maidenhead.arm.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2002-09/txt/msg00184.txt.bz2 Thanks a lot to Keith and Elias for their reply. Things are a little bit clearer now for me as regards the section .debug_info in Elf object files and the dwarf2 specification. I tried to make gcc produce an assembly language output from a C file (options -S and -g). I noticed that gcc included into the assembly output all necessary directives for the .debug_info section to be generated into the object file. I infer from that observation that whoever produces the assembly language source taken as input by the assembler stage, either an assembly language programmer or a C or high level language front end compiler, has the responsability to include the code for creating the .debug_info section and describing its contents. Am I wrong ? In any case, I wonder what is the exact purpose of the option --gdwarf2 of gas ? : On one hand, if it is supposed to make the .debug_info section be generated, the latter should include all relevant debugging information. On the other hand, if it not supposed to make the .debug_info section be created, what is its use ? I also noticed that option -g passed to the C compiler is sufficient for getting a .debug_info section. So my question is : why would I use the option -gdwarf-2 instead of -g ?... Pierre "Keith.Walker" wrote: > > >Knowing that rises several questions: > > > >- what is the structure of a '.debug_info' section ? > > Is this structure documented somewhere ? > > Yes ..... > > The web site http://www.eagercon.com/dwarf/dwarf3std.htm contains both the > original DWARF2 specification and the (almost) current DWARF3 draft. [A > later draft can be found at > http://reality.sgiweb.org/davea/dwarf3-draft8-011125.pdf ] > > >- which tool can be used to examine the contents of a '.debug_info' > > section ? I tried to use arm-elf-objdump but the result which it > > displays is not formatted and checking it is not easy... > > Try arm-elf-readelf > > >- is there a way to force gas to include a field 'DW_AT_name' in the > > object files it produces ? > > (an option on the command line ? a directive inside the source file ?) > > I haven't looked but I suspect there isn't a command line option; more > likely this will require a source change in binutils. > > >- why would gdb be not able to retrieve an assembly language source file > > (together with its name) as long as no breakpoint is set by the user > > within this file, where it is able to retrieve this same source file > > as soon as a first breakpoint is set (though the name of the source > > file is not present in the object file) ?... > > The following is only what I suspect is happening (I haven't actually > looked at the code). > > On initial load the debugger uses the DW_AT_name attribute specified in the > DW_TAG_compile_unit tags in order to determine the names of the initial > source files. As there is no DW_AT_name for assembler files they aren't > added to the initial list of source files. > > However when a breakpoint is set it reads the line number table for the > area/region in which the addess is located; the line number contains the > names of all the files associated with that table. Therefore at this > point it now knows about the assembler file. > > Keith > Keith Walker keith.walker@arm.com Tel:+44 (1628) 427732 > ARM Ltd http://www.arm.com -- ________________________________________________________________________ Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87 IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex ________________________________________________________________________