Re: [PATCH] Dwarf location expressions, tracing and printing

[Stan Shebs <stan@codesourcery.com>]

Stan Shebs wrote:
> This patch solves a number of problems related to variables with 
> Dwarf2 location expressions - which these days, means just about every 
> local in optimized code. :-)  Perhaps the most interesting part is 
> that I finally got tired of working blind and filled out description 
> location functions, so now both "info scope" and "info address" have 
> quite a lot of say about variables.  Try things like "info scope 
> handle_inferior_event" to get some truly awesome verbiage. :-)
>
> Since there's a lot of new code here, I'll leave it up for a couple 
> days before committing.
>

Just as a heads-up, this patch exposes a major hole in our tracepoint 
machinery when running testsuite with gdbserver - namely that agent 
expressions don't have a way to deal with registers that are larger than 
64 bits.  This crops up in gdb.trace/collection.exp:reglocal_test_func 
on x86, in which the local floats are assigned to $stX registers, which 
are 10 bytes long.  gdbserver properly chokes on any attempt to push 
these on the expression stack (although one might argue that it should 
be a tracing rather than internal error).  Previously, the registers 
were incorrectly numbered to 4-byte registers, which resulted in four 
FAILs when printing collected floats, but nothing worse.

I went ahead and committed the patch anyway, because the fix/workaround 
isn't obvious, and it's a design problem elsewhere.

Alternatives include:

1) Make the expression stack wider.  The existing target-side 
implementations are designed around the 64-bit assumption, so there 
would be some messy fixing-up with sign extensions and the like.

2) Generate bytecodes to handle larger registers as multiple pieces.

3) Disallow larger registers in expressions.

4) Stub out that part of the testsuite. :-)

Stan