Re: Section .debug_info in object file

[Pierre Habraken <Pierre.Habraken@imag.fr>]

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
________________________________________________________________________