RE: gdb bug or corrupt dwarf info?

["Elmenthaler, Jens" <JENS dot ELMENTHALER at advantest dot com>]

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