Re: [rfc] Decode "is a variable with complex or multiple locations" (PR 8399)

[Roland McGrath <roland@redhat.com>]

> (gdb) info address val
> Symbol "val" is a variable with multiple locations, for PC inclusive - exclusive:
> 0x5157c9 - 0x5157e9: stored relative to frame base at offset -20 
> 0x5157e9 - 0x5157f2: stored relative to register rsp at offset 60
> 0x5157f2 - 0x515835: stored relative to frame base at offset -20 
> and optimized out in ranges not covered above.

My hero!

> (a) While it does what `info address' should do I think you (+me) wished more
>     just the single line valid for the current PC.

Actually I think "info address" as it stands probably ought to print just
the one for the current PC, that seems most consistent with what it does
when it works.  But there should be easy ways to get both the current
location and all the locations for that name in the current scope, and I
don't really care what the command syntax is for either of them.

>     This would do `info scope *$pc' but that one prints _all_ the visible
>     variables with no way how to request just one variable.

To me it seems most usefully concise for "info scope *PC" to give only the
locations that actually apply at PC, most of the time.  (It would be dwimmy
to have "info scope foo.c:23" or "info scope func" to make the constraint
be all PCs that the expression implies as given, but I don't imagine that
is what the natural division of labor makes straightforward to do.)  As
with info addr, clearly one wants both options available somehow.

Perhaps:
	info addr sym		<-- as above, all PCs for sym in current scope
	info addr sym *0x1234	<-- sym (resolved as per "scope *0x1234")
	     	      		    location for 0x1234 only 
	info scope *0x1234	<-- full details about locals in "scope *0x1234"
	info scope *0x1234 *0x1234 <-- those locals' locations at PC=0x1234 only

>     One IMO expects info on `struct value' (with its lvalue address incl.
>     registers) than on `struct dwarf2_locexpr_baton' (DWARF block content).

I don't follow this part.

> (b) It prints it in a human readable format so more complex expressions are still
>     not decoded.

That wins for a huge majority of cases, I'm sure.  The plain expression
dump (as by readelf) would make me more than happy enough (though giving
appropriate $names to the DWARF register operations would be spiffy), but
I'd be satisfied enough for now with just a symfile name + hex DIE offset
to tell me what DWARF to go decode myself. 

> (c) "a variable in register rsi" vs. "DW_OP_reg4":

If you are printing things in DWARF-speak it is not really a big deal one
way or the other to have register names vs numbers, just a nicety.  The
person reading this sort of output is already expected to grok DWARF magic.
Whenever the whole story is explainable in human terms instead of
DWARF-speak, that is clearly the better default feature.  (Of course
someone like me would always like more options to tell me precise DWARF
bits, but I'm funny that way.)


Thanks,
Roland