This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Section .debug_info in object file
- From: Pierre Habraken <Pierre dot Habraken at imag dot fr>
- To: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Cc: "Keith.Walker" <Keith dot Walker at arm dot com>, Elias Athanasopoulos <eathan at otenet dot gr>
- Date: Sat, 14 Sep 2002 13:49:27 +0200
- Subject: Re: Section .debug_info in object file
- Organization: Université Joseph Fourier
- References: <4.1.20020912105556.01e79f10@mhsun1.maidenhead.arm.com>
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
________________________________________________________________________