Re: [patch/rfc] Recognize non-DW_AT_location <value optimized out> symbols

[Joel Brobecker <brobecker@adacore.com>]

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

> > * zero-length DW_AT_location should be the same as missing DW_AT_location.
> >   https://fedorahosted.org/pipermail/elfutils-devel/2009-March/000180.html

Here a few thoughts after looking more closely at this. After reproducing
the problem thanks to your testsuite patch, I initially did the same thing
as you did, which was to add the symbol for local symbols as well.

But that caused the regressions you mentioned in one of the C++ testcases.
It's about a variable that's declared inside an anonymous namespaces.
I think that our mistake was to add all non-external variables without
checking that they were "complete" yet. Thus, I changed the patch to
the attached. Basically, if it is a non-external symbol but at the same
time a "declaration", then we should wait for the "defining" declaration
before adding it to the current local scope.

That fixes the C++ problem, and I was fairly confident about it but
a testcase run seems to indicate the following regressions:

+------------+------------+----------------------------------------------------+
|       PASS | FAIL       | callfuncs.exp: gdb function calls preserve reg ... |
|            |            | ... ister contents                                 |
|       PASS | FAIL       | callfuncs.exp: continue after stop in call dum ... |
|            |            | ... my preserves register contents                 |
|       PASS | FAIL       | callfuncs.exp: finish after stop in call dummy ... |
|            |            | ...  preserves register contents                   |
|       PASS | FAIL       | callfuncs.exp: return after stop in call dummy ... |
|            |            | ...  preserves register contents                   |
|       PASS | FAIL       | callfuncs.exp: nested call dummies preserve re ... |
|            |            | ... gister contents                                |
+------------+------------+----------------------------------------------------+

I'm a little surprised at these regressions, as I don't see how
the dwarf2read change we're making can have an impact on this.
It's particularly more puzzling that I did a diff of the exact
output of before and after taken from the gdb.log file, and diff
said there was no difference. I'm rerunning the testsuite now,
to see if it might be transient, but I'm wondering if I'm looking
at the right reference output....

-- 
Joel

[-- Attachment #2: loc.diff --]
[-- Type: text/x-diff, Size: 666 bytes --]

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index feb57b0..cba9d75 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -7658,6 +7658,12 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu)
 		  SYMBOL_CLASS (sym) = LOC_UNRESOLVED;
 		  add_symbol_to_list (sym, &global_symbols);
 		}
+              else if (!die_is_declaration (die, cu))
+                {
+                  /* Use the default LOC_OPTIMIZED_OUT class.  */
+                  gdb_assert (SYMBOL_CLASS (sym) == LOC_OPTIMIZED_OUT);
+                  add_symbol_to_list (sym, cu->list_in_scope);
+                }
 	    }
 	  break;
 	case DW_TAG_formal_parameter: