[RFA/DWARF] variables with no DW_AT_location

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

We came across a case where GNAT generated some debugging info for
a local variable, but no DW_AT_location. As a result, the debugger
ended up not "seeing" that variable.

        (gdb) p subp
        No definition of "subp" in current context.

After investigation, it appeared that the variable was actually optimized
away by the compiler.  Although we were later able to link it to one of
its temporary location, so the symptoms disappeared.

But I had a look at the DWARF reference, and it says that the missing
attribute means that the variable was optimized away. I propose to change
GDB to print "optimized out" in this case.

The simplest way of doing this was to take advantage of the fact that
the dwarf2read module sets the symbol class of such variables to
LOC_UNRESOLVED, and then modify the code in findvar to return an
"optimized out" value rather than no value at all.

To be honest, I find the logic in read_var_value for LOC_UNRESOLVED
types to be a bit questionable: We revert to minimal symbols if the
debugging info does not provide the location. But if the variable was
indeed optimized out, what really proves that we are picking up the
same symbol? The one we're interested in could be a local variable
that was optimized away while the one found by GDB in the symbol
table could be another global variable that happens to have the same
name.

However, I tried adjusting dwarf2read to avoid setting the class
to LOC_UNRESOLVED, but then starting hitting other problems (one was
a dereference of a NULL type). I'm doing this on my own time, so
I'm wondering what you guys think of the approach is suggesting in
this patch.

2007-03-28  Joel Brobecker  <brobecker@adacore.com>

        * findvar.c (read_var_value): Return optimized-out values for
        LOC_UNRESOLVED symbols when we cannot find an associated
        minimal symbol.

I have create a new testcase for this. But the change also affects
one of the tests in gdb.cp. I think it's OK, although GDB is a bit
less verbose. I have attached a proposed update of this testcase.

2007-03-28  Joel Brobecker  <brobecker@adacore.com>

        * gdb.dwarf2/dw2-noloc.S: New file.
        * gdb.dwarf2/dw2-noloc.exp: New file.
        * gdb.cp/m-static.exp: Minor adjustment to new GDB output.

Tested on x86-linux.

OK to apply?
-- 
Joel

Attachment: no_at_loc.diff
Description: Text document

Attachment: dw2-noloc.S
Description: Text document

Attachment: dw2-noloc.exp
Description: Text document