Section .debug_info in object file

Section .debug_info in object file

[Pierre Habraken]

A few days ago I posted a message about the fact that after launching
gdb to debug a program made of several C and Arm assembly language
files, the command 'info sources' lists C files only.

Richard explained me that the section '.debug_info' in a given object
file is supposed to contain a field (among others) named 'DW_AT_name'
containing the name of the source file from which this object file was
produced.
It appears that assembly object files (at least those which are produced
by Gas) does not include this field 'DW_AT_name' ; this could explain
that gdb does not see assembly language source files at the time it
opens the program being debugged.

Knowing that rises several questions:

- what is the structure of a '.debug_info' section ?
  Is this structure documented somewhere ?

- 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...

- 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 ?)

- 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) ?...

Thanks for any help.

Pierre

PS: I am using binutils 2.13 and gdb 5.2.1 compiled for arm-elf.
-- 
________________________________________________________________________
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
________________________________________________________________________

Re: Section .debug_info in object file

[Keith.Walker]

>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

[PATCH] Re: Section .debug_info in object file

[Elias Athanasopoulos]

On Thu, Sep 12, 2002 at 11:42:33AM +0200, Pierre Habraken wrote:
> A few days ago I posted a message about the fact that after launching
> gdb to debug a program made of several C and Arm assembly language
> files, the command 'info sources' lists C files only.

I have attached a far from complete patch. It adds the first source file
name in the .debug_info section. This patch will not help you much, but
it solves a bug when both gcc and gas are used with dwarf2 support on. In the
latter case readelf reports garbage such as:

<0><bf>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_stmt_list   : 0      
DW_AT_high_pc     : 0x8048410 134513680    
DW_AT_low_pc      : 0x804841a 134513690    
DW_AT_name        : /home/anteater/test    
DW_AT_comp_dir    : GNU AS 2.11.90.0.8     
DW_AT_producer    : Β€=     
DW_AT_language    : 0      (Unknown: 0)

I check that with gcc 2.96. 

Elias

gas/ChangeLog

2002-09-12  Elias Athanasopoulos  <eathan@otenet.gr>

	* dwarf2dbg.c (out_debug_abbrev): Add support for the DW_AT_name field.
	(out_debug_info): Likewise.


--- dwarf2dbg.c.orig	Thu Sep 12 20:05:23 2002
+++ dwarf2dbg.c	Thu Sep 12 21:38:21 2002
@@ -1149,6 +1149,7 @@
       out_abbrev (DW_AT_low_pc, DW_FORM_addr);
       out_abbrev (DW_AT_high_pc, DW_FORM_addr);
     }
+  out_abbrev (DW_AT_name, DW_FORM_string);
   out_abbrev (DW_AT_comp_dir, DW_FORM_string);
   out_abbrev (DW_AT_producer, DW_FORM_string);
   out_abbrev (DW_AT_language, DW_FORM_data2);
@@ -1224,6 +1225,15 @@
       emit_expr (&expr, sizeof_address);
     }
 
+  /* DW_AT_name 
+   * FIXME: we only store the first source
+   * file, but we should add more records to
+   * .debug_info for each source file we assemble.
+   */  
+  len = strlen (files[1].filename) + 1;
+  p = frag_more (len);
+  memcpy (p, files[1].filename, len);
+                 
   /* DW_AT_comp_dir */
   comp_dir = getpwd ();
   len = strlen (comp_dir) + 1;


-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: [PATCH] Re: Section .debug_info in object file

[Richard Henderson]

On Thu, Sep 12, 2002 at 10:03:03PM +0300, Elias Athanasopoulos wrote:
> 	* dwarf2dbg.c (out_debug_abbrev): Add support for the DW_AT_name field.
> 	(out_debug_info): Likewise.

I suppose we could do something like this.

But it seems to me that this is a gdb bug.  The complete file+line
mapping is available in .debug_line.  What purpose does the AT_name
field of the compilation unit serve?

> +   * FIXME: we only store the first source
> +   * file, but we should add more records to
> +   * .debug_info for each source file we assemble.

Definitely not.



r~

Re: [PATCH] Re: Section .debug_info in object file

[Elias Athanasopoulos]

On Thu, Sep 12, 2002 at 01:54:34PM -0700, Richard Henderson wrote:
> On Thu, Sep 12, 2002 at 10:03:03PM +0300, Elias Athanasopoulos wrote:
> > 	* dwarf2dbg.c (out_debug_abbrev): Add support for the DW_AT_name field.
> > 	(out_debug_info): Likewise.
> 
> I suppose we could do something like this.
> 
> But it seems to me that this is a gdb bug.  The complete file+line
> mapping is available in .debug_line.  What purpose does the AT_name
> field of the compilation unit serve?

Maybe gdb can grab the info from .debug_line, but still gcc uses 
DW_AT_name for (every) C source file and this conflicts with gas which 
skips this field (readelf, as I wrote, produces garbage). 

Elias

-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: Section .debug_info in object file

[Pierre Habraken]

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
________________________________________________________________________

Re: [PATCH] Re: Section .debug_info in object file

[Elias Athanasopoulos]

Hi Richard,

On Thu, Sep 12, 2002 at 01:54:34PM -0700, Richard Henderson wrote:
> On Thu, Sep 12, 2002 at 10:03:03PM +0300, Elias Athanasopoulos wrote:
> > 	* dwarf2dbg.c (out_debug_abbrev): Add support for the DW_AT_name field.
> > 	(out_debug_info): Likewise.
> 
> I suppose we could do something like this.
> 
> But it seems to me that this is a gdb bug.  The complete file+line
> mapping is available in .debug_line.  What purpose does the AT_name
> field of the compilation unit serve?

After some short investigation I concluded that gdb stores in the
symtable along with the file name (which is taken from DW_AT_name) the
lowpc field (DW_AT_low_pc). This happens inside dwarf2_build_psymtabs_hard():

      /* Allocate a new partial symbol table structure */
      pst = start_psymtab_common (objfile, objfile->section_offsets,
                                  comp_unit_die.name ? comp_unit_die.name : "",
				  comp_unit_die.lowpc,
				  objfile->global_psymbols.next,
	                          objfile->static_psymbols.next);

I guess this information can be taken also from .debug_line. Do we want
to build the symtable using .debug_line instead of .debug_info?

Also, about my previous patch, gcc includes the DW_AT_name field in 
.debug_abbrev, but gas does not. So, readelf expects to find a DW_AT_name
field in .debug_info section, which is created by gas. I believe that gas
should export the DW_AT_name in the .debug_info section, otherwise utilities
such as readelf will have problems parsing the debug information correctly.

Elias

-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: Section .debug_info in object file

[Keith.Walker]

At 01:49 PM 14-09-02 +0200, Pierre Habraken wrote:
>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 ?

When the assembler is invoked by the compiler to assemble the code
generated for compiled sources the assembler should NOT be invoked with the
-gdwarf2.    The compiler supplies the DWARF2 debugging information for the
sources being compiled by the compiler.    It is therefore the
responsibility of the compiler to supply the DWARF2 information to describe
the source file being compiled.

When the assembler is being invoked to assembler user supplied assembler
files then the -gdwarf2 flag can be used to make the assembler generate the
DWARF2 debugging information which describes the assembler file.     [This
is primarily the line to address table.]    In this case it is the
responsibility of the assembler to supply the DWARF2 information to
describe the  file being assembled.

>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 ?...

gcc can be build for different targets (e.g. arm-elf-gcc, arm-linux-gcc).
  When you use -g the compiler will generate the debugging information in
the default format for the appropriate target.     For arm-elf-gcc this is
usually DWARF2 and for arm-linux-gcc this is usually STABS.        The
-gdwarf2 flag therefore overides the default format and explicitly
specifies that DWARF2 debuggging information is required.

Keith

Keith Walker		keith.walker@arm.com		Tel:+44 (1628) 427732
ARM Ltd		http://www.arm.com

Re: Section .debug_info in object file

[Elias Athanasopoulos]

On Mon, Sep 16, 2002 at 11:13:59AM +0100, Keith.Walker wrote:
> When the assembler is invoked by the compiler to assemble the code
> generated for compiled sources the assembler should NOT be invoked with the
> -gdwarf2.    The compiler supplies the DWARF2 debugging information for the

If this is the case, I believe we have to add a warning message.

Elias

-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: Section .debug_info in object file

[Pierre Habraken]

"Keith.Walker" wrote:
> [...]
> When the assembler is being invoked to assembler user supplied assembler
> files then the -gdwarf2 flag can be used to make the assembler generate the
> DWARF2 debugging information which describes the assembler file.     [This
> is primarily the line to address table.]    In this case it is the
> responsibility of the assembler to supply the DWARF2 information to
> describe the  file being assembled.

Ok. So, I understand that this is a bug in Gnu As if the attribute
DW_AT_name is not added to the tag DW_TAG_compile_unit in the object
file...

Pierre
-- 
________________________________________________________________________
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
________________________________________________________________________

Re: [PATCH] Re: Section .debug_info in object file

[Richard Henderson]

On Sun, Sep 15, 2002 at 12:42:58PM +0300, Elias Athanasopoulos wrote:
> Also, about my previous patch, gcc includes the DW_AT_name field in 
> .debug_abbrev, but gas does not. So, readelf expects to find a DW_AT_name
> field in .debug_info section, which is created by gas.

No it doesn't.  readelf prints the .debug_info+.debug_abbrev
sections exactly as presented.  The existence of DW_AT_name
makes no difference one way or the other.


r~

Re: [PATCH] Re: Section .debug_info in object file

[Richard Henderson]

On Thu, Sep 12, 2002 at 10:03:03PM +0300, Elias Athanasopoulos wrote:
> 	* dwarf2dbg.c (out_debug_abbrev): Add support for the DW_AT_name field.
> 	(out_debug_info): Likewise.

I committed the following variant.


r~



Index: dwarf2dbg.c
===================================================================
RCS file: /cvs/src/src/gas/dwarf2dbg.c,v
retrieving revision 1.53
diff -c -p -d -r1.53 dwarf2dbg.c
*** dwarf2dbg.c	27 Aug 2002 11:09:42 -0000	1.53
--- dwarf2dbg.c	17 Sep 2002 02:32:00 -0000
*************** out_debug_abbrev (abbrev_seg)
*** 1149,1154 ****
--- 1149,1155 ----
        out_abbrev (DW_AT_low_pc, DW_FORM_addr);
        out_abbrev (DW_AT_high_pc, DW_FORM_addr);
      }
+   out_abbrev (DW_AT_name, DW_FORM_string);
    out_abbrev (DW_AT_comp_dir, DW_FORM_string);
    out_abbrev (DW_AT_producer, DW_FORM_string);
    out_abbrev (DW_AT_language, DW_FORM_data2);
*************** out_debug_info (info_seg, abbrev_seg, li
*** 1223,1228 ****
--- 1224,1239 ----
        expr.X_add_number = 0;
        emit_expr (&expr, sizeof_address);
      }
+ 
+   /* DW_AT_name.  We don't have the actual file name that was present
+      on the command line, so assume files[1] is the main input file.
+      We're not supposed to get called unless at least one line number
+      entry was emitted, so this should always be defined.  */
+   if (!files || files_in_use < 1)
+     abort ();
+   len = strlen (files[1].filename) + 1;
+   p = frag_more (len);
+   memcpy (p, files[1].filename, len);
  
    /* DW_AT_comp_dir */
    comp_dir = getpwd ();