gdb bug or corrupt dwarf info?

gdb bug or corrupt dwarf info?

[Elmenthaler, Jens]

Hi,

I'm currently investigation why gdb is only showing 'i' as local variable in the following loop body, and not also 'text':

 for (int i = 0; i < 5; i++) {
    const char *text = "sabel";
    cerr << "text=" << text << endl; // Suspended here
}

The corresponding output of objdump -W yields the following:

<2><74105>: Abbrev Number: 264 (DW_TAG_lexical_block)
     DW_AT_sibling     : <7411e>	
     DW_AT_ranges      : 0	
 <3><7410f>: Abbrev Number: 235 (DW_TAG_variable)
     DW_AT_name        : i	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 6962	
     DW_AT_type        : <23cd>	
     DW_AT_location    : 2 byte block: 91 68 	(DW_OP_fbreg: -24)
 <2><7411e>: Abbrev Number: 245 (DW_TAG_lexical_block)
     DW_AT_low_pc      : 0x7b108	
     DW_AT_high_pc     : 0x7b14c	
 <3><74128>: Abbrev Number: 235 (DW_TAG_variable)
     DW_AT_name        : text	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 6963	
     DW_AT_type        : <11f85>	
     DW_AT_location    : 2 byte block: 91 6c 	(DW_OP_fbreg: -20)

Contents of the .debug_ranges section:

    Offset   Begin    End
    00000000 0007b0dd 0007b0f2 
    00000000 0007b108 0007b156 
    00000000 <End of list>


So my question now is, whether this is a gdb bug which I possibly could fix, or whether the debug info is broken.

In my opinion it looks suspicious that the lexical block containing 'text' is not a child of the lexical block containing 'i', but a sibling.

Can someone provide a hint?

Greetings, Jens.

Re: gdb bug or corrupt dwarf info?

[Tom Tromey]

>>>>> "Jens" == Elmenthaler, Jens <JENS.ELMENTHALER@advantest.com> writes:

Jens> I'm currently investigation why gdb is only showing 'i' as local
Jens> variable in the following loop body, and not also 'text':

Jens> So my question now is, whether this is a gdb bug which I possibly
Jens> could fix, or whether the debug info is broken.

Jens> In my opinion it looks suspicious that the lexical block
Jens> containing 'text' is not a child of the lexical block containing
Jens> 'i', but a sibling.

I am not sure if it is invalid DWARF.  There isn't much in DWARF that
prohibits odd output like this.  Maybe such a prohibition is in there --
I couldn't quickly find it, but that isn't definitive.

This DWARF is definitely not what gdb expects.  gdb expects lexical
blocks to be nested and not to overlap.  However, see the "???" comment
in read_lexical_block_scope -- there appears to be some room for
improvement, though it is unclear to me if trying to handle the DWARF
you have is worth the effort.  In particular the comment refers to how
to handle disjoint ranges, but your problem is both disjoint ranges in
one scope combined with an overlap of another scope.

I would say that it is both a compiler bug and a gdb bug.
The blocks ought to nest, and there doesn't seem to me to be a good
reason to use the representation you are seeing.

Tom

RE: gdb bug or corrupt dwarf info?

[Elmenthaler, Jens]

Tom, thanks for your quick answer.  This type of debug info indeed seems to depend on the gcc version. I tried a gcc 4.7.2 and the debug info looks all nice and clean.

Unfortunately, my target environment is a RedHat 5.8 with a gcc 4.1.2. and upgrading the gcc is not an option. All I can touch is the gdb.

So I developed a patch, applying the following reasoning:
- The bug is that a child lexical scope is erroneously output as the successor sibling of the parent
- if lexical block scope A is a real sibling of lexical block scope B, the address range of A will not be a subrange of B, nor vice versa.
- So I can detect a bogus child by looking at the successor sibling. If the successor sibling's address range is a subrange of the predecessor sibling, I treat it as a child.

I added the following code to read_lexical_block_scope(), right behind the processing of the children. In case the test is positive, I "repair" the affected die_info's:

  struct die_info *sibling = sibling_die(die);
  if (sibling && (sibling->tag == DW_TAG_lexical_block))
    {
      CORE_ADDR sibling_lowpc, sibling_highpc;
      if (dwarf2_get_pc_bounds(sibling, &sibling_lowpc, &sibling_highpc, cu, NULL ))
        {
          sibling_lowpc += baseaddr;
          sibling_highpc += baseaddr;
          if (lowpc <= sibling_lowpc && sibling_highpc <= highpc)
            {
              die->sibling = sibling->sibling;
              sibling->sibling = NULL;
              sibling->parent = die;

              if (die->child)
                {
                  struct die_info *child;
                  for (child = die->child; sibling_die(child); child = sibling_die(child))
                    {
                    }
                  child->sibling = sibling;
                }
              else
                {
                  die->child = sibling;
                }

              process_die(sibling, cu);
            }
        }
    }

First tests seem promising, so is there any reason I shouldn't do this?

Jens.

-----Original Message-----
From: Tom Tromey [mailto:tromey@redhat.com] 
Sent: Thursday, March 28, 2013 9:46 PM
To: Elmenthaler, Jens
Cc: gdb@sourceware.org
Subject: Re: gdb bug or corrupt dwarf info?

>>>>> "Jens" == Elmenthaler, Jens <JENS.ELMENTHALER@advantest.com> writes:

Jens> I'm currently investigation why gdb is only showing 'i' as local 
Jens> variable in the following loop body, and not also 'text':

Jens> So my question now is, whether this is a gdb bug which I possibly 
Jens> could fix, or whether the debug info is broken.

Jens> In my opinion it looks suspicious that the lexical block 
Jens> containing 'text' is not a child of the lexical block containing 
Jens> 'i', but a sibling.

I am not sure if it is invalid DWARF.  There isn't much in DWARF that prohibits odd output like this.  Maybe such a prohibition is in there -- I couldn't quickly find it, but that isn't definitive.

This DWARF is definitely not what gdb expects.  gdb expects lexical blocks to be nested and not to overlap.  However, see the "???" comment in read_lexical_block_scope -- there appears to be some room for improvement, though it is unclear to me if trying to handle the DWARF you have is worth the effort.  In particular the comment refers to how to handle disjoint ranges, but your problem is both disjoint ranges in one scope combined with an overlap of another scope.

I would say that it is both a compiler bug and a gdb bug.
The blocks ought to nest, and there doesn't seem to me to be a good reason to use the representation you are seeing.

Tom

Re: gdb bug or corrupt dwarf info?

[Tom Tromey]

>>>>> "Jens" == Elmenthaler, Jens <JENS.ELMENTHALER@advantest.com> writes:

Jens> I added the following code to read_lexical_block_scope(), right
Jens> behind the processing of the children. In case the test is
Jens> positive, I "repair" the affected die_info's:

Jens>   struct die_info *sibling = sibling_die(die);
Jens>   if (sibling && (sibling->tag == DW_TAG_lexical_block))

Is it valid to assume that the two DIEs will be siblings?
Maybe that is the only way the bug can manifest.  You may want to check.

Jens> First tests seem promising, so is there any reason I shouldn't do this?

It seems like it could work ok.

Tom