This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: implement DW_OP_bit_piece


Tom Tromey wrote:
I am less sanguine about updating the tracepoint code, I suppose because
it is pretty new and yet doesn't implement even what was already in gdb
when it went in:

if (bytes != 4)
error (_("DW_OP_piece %s not supported in location for \"%s\"."),
pulongest (bytes), SYMBOL_PRINT_NAME (symbol));

Touche' :-)


I did dig around in the code a little, and it turns out I'm also not
clear on all the details I would need to implement the support.

I don't really see how DWARF expressions can work with the current
setup.  Maybe just some subset can -- but then I would like to
understand how the subset is chosen, I guess so I can argue against
choosing DW_OP_bit_piece ;-).  Ok, seriously...

For instance, I don't understand how a DWARF expression involving a
conditional could work.  You could compile DWARF to AX, including the
condition.  But then I think you'd have to circumvent the DWARF
expression when re-evaluating the expression at "replay" time (I don't
know the real name of the mode, sorry).


In theory, evaluation of the expression while examining a trace frame will just work, because the DWARF condition will evaluate to the same value as it would have when looking at the live state.


GCC is already emitting nontrivial DWARF. It can emit some stack ops
(look at the MOD case in dwarf2out.c). It can emit pieces and stack and
literal values. And, I think it can emit TLS references. So this is
not just hypothetical, today's expression translation is already
insufficient for today's GCC.

We've been special-casing things in the ax code as they've come along in real compiler output - your mention of bit pieces got my attention because it sounded like tracepoint test cases could start regressing if someone updated their GCC.


But yeah, this is the kind of thing that gets us to start muttering again about the common compilation / evaluation pathway idea. CodeSourcery's tracepoint work has already been decided for this year, and the closest related task is going to be some better handling of partially-collected values. But now is a good time to start thinking about what we should do in 2011; I can see things getting to the point where the common pathway is the easiest strategy for coping with ever-more-complex debug info from GCC.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]