Re: Section .debug_info in object file

["Keith.Walker" <Keith.Walker@arm.com>]

>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