Re: [PATCH] More C++ static fields for tracepoints

[Stan Shebs <stan@codesourcery.com>]

Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:
>>>>>>             
>
> Stan> This patch solves a couple intertwined problems relating to
> Stan> tracepoint collection of C++ classes with static fields.  First,
> Stan> it adds recognition of variables (including static fields) whose
> Stan> location expressions indicate that they have been optimized out.
>
> As ax-gdb grows I am starting to wonder whether we could unify it with
> eval.c somehow.
>   
"It would be nice."  There was some discussion in that general vein back 
around 2002-3, connected with dwarf2 computed locations; 
http://sourceware.org/ml/gdb-patches/2002-07/msg00124.html alludes to 
the idea for example.

Certainly it becomes compelling beyond tracepoints if you wanted to do 
something like breakpoint conditions on the target; as an additional 
teaser, one of the things we did for Ericsson was to JIT-style compile 
the agent bytecodes to x86 native, which gives condition-testing times 
close to what one would get for conditional code hand-written into the 
sources.

The downside is that GDB's evaluator frequently makes on-the-spot 
decisions about what to do next based on data pulled from the target, so 
abstracting all that out is going to be rather painful.
> Stan> Second, to collect an instance of a class with static fields, we
> Stan> need to issue more bytecodes, since static fields are stored at
> Stan> their own addresses, separately from the instance.
>
> A static field may itself be of a type with static fields.  That doesn't
> seem to be handled in this code... should it be?  And if so, be careful
> about the case where a class refers to itself recursively via static
> fields; we still have some printing bugs in this area :(
>   
Hmm, I'll check it out - I wonder it's flattened out, static field 
iteration doesn't seem to recurse as one might expect.

Stan