[PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Bob Wilson]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

The code for dwarf2_finish() in gas/dwarf2dbg.c appears to be inconsistent.  If 
you assemble a file that contains no instructions, e.g., just a symbol 
declaration: ".global some_symbol", with --gdwarf2, GAS will create a 
.debug_line section but no corresponding .debug_info section.  This is probably 
harmless for GDB, but it breaks readelf, which expects a one-to-one 
correspondence between .debug_info and .debug_line sections.  Running "readelf 
-wl" on such a file results in the following error message:

   readelf: Error: Not enough comp units for .debug_lines section

It looks like the problem was introduced by the following change:

2002-08-01  H.J. Lu  <hjl@gnu.org>
	    Daniel Jacobowitz  <drow@mvista.com>

	* dwarf2dbg.c (dwarf2_finish): Don't emit unreferenced
	.debug_line section unless it has line information.

I read through the discussions surrounding that patch to try to understand the 
issues involved, but I'm not sure if I succeeded.  I _think_ this patch is 
correct -- assuming the .debug_info section is needed, it must either be 
provided in the input or generated later in dwarf2_finish.  In the latter case, 
the test to "do nothing" should be consistent with the test to generate 
.debug_info, etc.  An alternative would be changing GAS to write out a 
.debug_info section even when no line numbers are specified, but the following 
comment in out_debug_info() suggests that might not work: "We're not supposed to 
get called unless at least one line number entry was emitted...."

I'll be happy to commit this if someone will confirm that it is the right thing 
to do and approve the patch.  It doesn't cause any gas testsuite regressions for 
an xtensa-elf target.

--Bob


gas ChangeLog
2004-11-15  Bob Wilson  <bob.wilson@acm.org>

	* dwarf2dbg.c (dwarf2_finish): Don't write a .debug_line section
	without a corresponding .debug_info section.


[-- Attachment #2: dwarf2dbg.patch --]
[-- Type: text/plain, Size: 944 bytes --]

Index: dwarf2dbg.c
===================================================================
RCS file: /cvs/src/src/gas/dwarf2dbg.c,v
retrieving revision 1.71
diff -u -p -r1.71 dwarf2dbg.c
--- dwarf2dbg.c	2 Nov 2004 09:49:25 -0000	1.71
+++ dwarf2dbg.c	15 Nov 2004 18:53:45 -0000
@@ -1356,13 +1356,12 @@ dwarf2_finish (void)
   struct line_seg *s;
 
   /* We don't need to do anything unless:
-     - Some debug information was recorded via .file/.loc
-     - or, we are generating DWARF2 information ourself (--gdwarf2)
+     - Some debug information was recorded via .file/.loc or
+       generated by GAS (--gdwarf2)
      - or, there is a user-provided .debug_info section which could
        reference the file table in the .debug_line section we generate
        below.  */
   if (all_segs == NULL
-      && debug_type != DEBUG_DWARF2
       && (bfd_get_section_by_name (stdoutput, ".debug_info") == NULL
 	  || files_in_use == 0))
     return;

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Alan Modra]

On Mon, Nov 15, 2004 at 11:27:13AM -0800, Bob Wilson wrote:
> probably harmless for GDB, but it breaks readelf, which expects a 
> one-to-one correspondence between .debug_info and .debug_line sections.  

I would say that this is a readelf bug.  The only reason that readelf
needs .debug_info when dumping .debug_line is to find the size of
addresses.  readelf could guess that some other way.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Nick Clifton]

Hi Alan, Hi Bob,

>>probably harmless for GDB, but it breaks readelf, which expects a 
>>one-to-one correspondence between .debug_info and .debug_line sections.  

> I would say that this is a readelf bug.  The only reason that readelf
> needs .debug_info when dumping .debug_line is to find the size of
> addresses.  readelf could guess that some other way.

I do not think so - the DWARF standard does specify that there there 
should be a correspondence between the compilation units in the 
.debug_info section and the compilation units in the .debug_line section:

   From "Section 6.2 Line number Information":

   As mentioned in Section 3.1.1, the line number information
   generated for a compilation unit is represented in the
   .debug_line section of an object file and is referenced by
   corresponding compilation unit debugging information entry
   in the .debug_info section.

As for the patch itself - I am not so sure.  It looks to me like there 
might be problems when -gdwarf2 is not specified on the command line. 
ie GAS might still generate dwarf2 debug sections.  I would need to have 
a look at this and I am really swamped at the moment. :-(   Bob - could 
you try a few more tests of your patch please ?  Say with various 
different -gxxx command line switches specified ?

Cheers
   Nick

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Alan Modra]

On Thu, Nov 18, 2004 at 08:43:52AM +0000, Nick Clifton wrote:
> Hi Alan, Hi Bob,
> 
> >>probably harmless for GDB, but it breaks readelf, which expects a 
> >>one-to-one correspondence between .debug_info and .debug_line sections.  
> 
> >I would say that this is a readelf bug.  The only reason that readelf
> >needs .debug_info when dumping .debug_line is to find the size of
> >addresses.  readelf could guess that some other way.
> 
> I do not think so - the DWARF standard does specify that there there 
> should be a correspondence between the compilation units in the 
> .debug_info section and the compilation units in the .debug_line section:
> 
>   From "Section 6.2 Line number Information":
> 
>   As mentioned in Section 3.1.1, the line number information
>   generated for a compilation unit is represented in the
>   .debug_line section of an object file and is referenced by
>   corresponding compilation unit debugging information entry
>   in the .debug_info section.

But that's the other way around, .debug_info references .debug_line.  In
this case we have .debug_line with no .debug_info, which should be OK.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Nick Clifton]

Hi Alan,

>>I do not think so - the DWARF standard does specify that there there 
>>should be a correspondence between the compilation units in the 
>>.debug_info section and the compilation units in the .debug_line section:
>>
>>  From "Section 6.2 Line number Information":
>>
>>  As mentioned in Section 3.1.1, the line number information
>>  generated for a compilation unit is represented in the
>>  .debug_line section of an object file and is referenced by
>>  corresponding compilation unit debugging information entry
>>  in the .debug_info section.

> But that's the other way around, .debug_info references .debug_line.  In
> this case we have .debug_line with no .debug_info, which should be OK.

Does that make sense though ?  A .debug_line compilation unit which does 
not correspond to any .debug_info compilation unit ?  What lines would 
it be describing ?  Why would these lines exist without any debug info ?

Cheers
   Nick

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Alan Modra]

On Thu, Nov 18, 2004 at 09:22:37AM +0000, Nick Clifton wrote:
> >But that's the other way around, .debug_info references .debug_line.  In
> >this case we have .debug_line with no .debug_info, which should be OK.
> 
> Does that make sense though ?  A .debug_line compilation unit which does 
> not correspond to any .debug_info compilation unit ?  What lines would 
> it be describing ?  Why would these lines exist without any debug info ?

.debug_line by itself gives you a mapping between addresses and source
file line numbers.  That might be all a tool needs.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Daniel Jacobowitz]

On Thu, Nov 18, 2004 at 10:28:14PM +1030, Alan Modra wrote:
> On Thu, Nov 18, 2004 at 09:22:37AM +0000, Nick Clifton wrote:
> > >But that's the other way around, .debug_info references .debug_line.  In
> > >this case we have .debug_line with no .debug_info, which should be OK.
> > 
> > Does that make sense though ?  A .debug_line compilation unit which does 
> > not correspond to any .debug_info compilation unit ?  What lines would 
> > it be describing ?  Why would these lines exist without any debug info ?
> 
> .debug_line by itself gives you a mapping between addresses and source
> file line numbers.  That might be all a tool needs.

Bob's original mail said it was harmless for GDB - but that's not true.
GDB will only read line number data associated with some compilation
unit.

Is there any reason not to emit a compilation unit, if there isn't one
already, and there is line number data?

-- 
Daniel Jacobowitz

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Bob Wilson]

Replying to several messages at once here....

Nick Clifton wrote:
> I do not think so - the DWARF standard does specify that there there
> should be a correspondence between the compilation units in the .debug_info
> section and the compilation units in the .debug_line section:

I agree with this.  Before submitting the patch, I considered Alan's suggestion 
that this is a bug in readelf, and regardless of what GAS generates, it does 
seem that readelf should only look for .debug_line sections that are referenced 
from .debug_info sections.  I'm not going to tackle that change now.  After 
reading the DWARF spec, I think it would be best to fix GAS.  I agree with Alan 
that the current situation is not explicitly prohibited by the DWARF spec, but 
keeping .debug_line sections tied to .debug_info sections would seem to better 
follow the spirit of the spec.

Alan Modra wrote:
> On Thu, Nov 18, 2004 at 09:22:37AM +0000, Nick Clifton wrote:
>>> Does that make sense though ?  A .debug_line compilation unit which does 
>>> not correspond to any .debug_info compilation unit ?  What lines would 
>>> it be describing ?  Why would these lines exist without any debug info ?
> 
> .debug_line by itself gives you a mapping between addresses and source
> file line numbers.  That might be all a tool needs.

That's irrelevant, though, because the situation in question occurs only when 
there is no debug line info.  dwarf2_finish is currently writing an (empty) 
.debug_line section even when there is no line number data.  The whole point of 
the patch is to fix that!  (Sorry, I guess I didn't make that clear earlier.)

Nick Clifton wrote:
> As for the patch itself - I am not so sure.  It looks to me like there might
> be problems when -gdwarf2 is not specified on the command line. ie GAS might
> still generate dwarf2 debug sections.  I would need to have a look at this
> and I am really swamped at the moment. :-(   Bob - could you try a few more
> tests of your patch please ?  Say with various different -gxxx command line
> switches specified ?

I just tried --gstabs and --gstabs+ for several input files, and I don't see any 
problems.

I think your concern is misplaced, i.e., the patch might not be correct, but it 
shouldn't cause GAS to generate "extra" dwarf2 debugging output.  Look at it 
this way: the patch removes one of the conditions required for dwarf2_finish to 
return without doing anything.  It can only increase the number of situations 
where dwarf2_finish does nothing.

Daniel Jacobowitz wrote:
> Bob's original mail said it was harmless for GDB - but that's not true.
> GDB will only read line number data associated with some compilation
> unit.

Well, I said it was *probably* harmless, and from what you say, I still think 
that.  GDB will ignore the "orphan" .debug_line section, but that's fine -- 
there's nothing there for GDB to see anyway.

> 
> Is there any reason not to emit a compilation unit, if there isn't one
> already, and there is line number data?

No, there is no reason not to emit a comp unit in that case, and it will be 
emitted in that case, both with and without my patch.  The patch is intended to 
address only the case where there is no line number data.

I hope that clears things up a bit.  As far as I can tell, this shouldn't be a 
big deal -- it's just tidying up an unusual corner case.

--Bob

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Daniel Jacobowitz]

On Thu, Nov 18, 2004 at 10:13:10AM -0800, Bob Wilson wrote:
> That's irrelevant, though, because the situation in question occurs only 
> when there is no debug line info.  dwarf2_finish is currently writing an 
> (empty) .debug_line section even when there is no line number data.  The 
> whole point of the patch is to fix that!  (Sorry, I guess I didn't make 
> that clear earlier.)

Oh, thanks!  That wasn't clear.


-- 
Daniel Jacobowitz

Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2

[Nick Clifton]

Hi Bob,

> I just tried --gstabs and --gstabs+ for several input files, and I don't 
> see any problems.
> 
> I think your concern is misplaced, i.e., the patch might not be correct, 
> but it shouldn't cause GAS to generate "extra" dwarf2 debugging output.  
> Look at it this way: the patch removes one of the conditions required 
> for dwarf2_finish to return without doing anything.  It can only 
> increase the number of situations where dwarf2_finish does nothing.

Fair enough.  Thank you for running the extra checks.  Please consider 
this patch approved and apply it when you can.

Cheers
   Nick