tracepoint implementation question

tracepoint implementation question

[Der Herr Hofrat]

HI !

 I'm playing with tracepoints and ran across a problem with the actions.

 I added the basic package handling as a set of dummy routines that basically
 print information for now only + a dummy handler that just prints when it
 got called. The test code on the target is:

void junk2(int *someint){
        int junk=1;
        printf("got %d (%d)\n",*someint,junk);
}

main(){
        int i=0;
        while(i<4){
                junk2(&i);
                sleep(1);
                i++;
        }
        return 0;
}


This basically is working

Host:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x400007b0 in ?? ()
(gdb) symbol-file gdbserver/hello
Reading symbols from /root/tracepoints/gdb-6.3-tp1/gdb/gdbserver/hello...done.
(gdb) trace junk2
Tracepoint 1 at 0x80483df: file hello.c, line 8.
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
> collect $regs
> end
(gdb) tstart
(gdb) c
Continuing.

Program exited normally.
(gdb)

Target:
received pkt (QTinit)
Q packet received (QTinit)
received pkt (QTDP:1:080483df:E:0:0-)
Q packet received (QTDP:1:080483df:E:0:0-)
tracepoint data (QTDP:1:080483df:E:0:0-)
tp request 1 at address 80483df (state: 1)
received pkt (QTDP:-1:080483df:R03FFFFFFFFFF)
Q packet received (QTDP:-1:080483df:R03FFFFFFFFFF)
tracepoint data (QTDP:-1:080483df:R03FFFFFFFFFF)
packet data tc 1: (R03FFFFFFFFFF)
continuation for tp 1 at address 80483df
received pkt (QTStart)
Q packet received (QTStart)
tracepoint start (QTStart)
received pkt (vCont?)
received pkt (vCont;c)
tp breakpoint triggert at 80483df
got 0 (1)
tp breakpoint triggert at 80483df
got 1 (1)
...

 Now I started adding the different actions and found that only 
 "collect $regs" seems to be supported/working on the host side.
 I get the register array and could now collect it in the handler 
 that is called - but if I try anything else like:

(gdb) actions 1
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
> collect someint
> end
(gdb) tstart
someint: don't know symbol class 21
(gdb)

no packet is obviously sent to the target - the same for args

(gdb) actions 1
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
> collect $args
> end
(gdb) tstart
warning: don't know how to trace local symbol someint
warning: No args found in scope.
(gdb)

The tracepoint is set but no information on the object to collect is sent
to the target.

Is there any docs on the details of tracepoints ? 
is this part of the gdb code actually actively maintained or am I wasting my 
time trying to get this to work ? 
Is there any further information on tracepoints available other than the 
protocol/packet spec - some sort of design doc ?

thx !
hofrat

Re: tracepoint implementation question

[Jim Blandy]

Actually, I think the problem you're running into is that the
debugging information in your executable is using Dwarf location
expressions to describe where the variables live, and the tracepoint
code isn't using the supplied functions to translate between Dwarf
location expressions and tracepoint bytecodes.

"Symbol class 21" is LOC_COMPUTED_ARG; the tracepoint code ought to be
calling the 'tracepoint_var_ref' function in the symbol's 'struct
symbol_ops' structure.  Probably we need a new function
gen_trace_for_symbol in ax-gdb.c, analogous to gen_trace_for_expr. 
Depending on the exact expression at hand, dwarf2_tracepoint_var_ref
may need to be expanded.

You're right, to some extent this indicates a lack of active
maintenance.  When the tracepoint code was written, few variables used
Dwarf expressions; now it is much more common.

Could you post the result of running 'readelf -wi' on your test
program (the one with 'someint' in it)?  (If the output is very large,
put it on the web and post a link.)

Re: tracepoint implementation question

[Der Herr Hofrat]

> Actually, I think the problem you're running into is that the
> debugging information in your executable is using Dwarf location
> expressions to describe where the variables live, and the tracepoint
> code isn't using the supplied functions to translate between Dwarf
> location expressions and tracepoint bytecodes.
> 
> "Symbol class 21" is LOC_COMPUTED_ARG; the tracepoint code ought to be
> calling the 'tracepoint_var_ref' function in the symbol's 'struct
> symbol_ops' structure.  Probably we need a new function
> gen_trace_for_symbol in ax-gdb.c, analogous to gen_trace_for_expr. 
> Depending on the exact expression at hand, dwarf2_tracepoint_var_ref
> may need to be expanded.
> 
> You're right, to some extent this indicates a lack of active
> maintenance.  When the tracepoint code was written, few variables used
> Dwarf expressions; now it is much more common.
> 
> Could you post the result of running 'readelf -wi' on your test
> program (the one with 'someint' in it)?  (If the output is very large,
> put it on the web and post a link.)
> 
Frist - thanks for the clarification - it would have taken me quite some time
to figure that out.
Second - the file is on the web at: http://dslab.lzu.edu.cn/hello.readelf

If I write up thos functions (no idea yet how hard that will be and if I can
actually do it), what would be the procedure to get these changes into GDB ?
The tracepoint implementation I should do is intended for release under GPL
so I would like to get it clean from the start.

thx !
hofrat

Re: tracepoint implementation question

[Jim Blandy]

On 3/20/06, Der Herr Hofrat <der.herr@hofr.at> wrote:
> Frist - thanks for the clarification - it would have taken me quite some time
> to figure that out.
> Second - the file is on the web at: http://dslab.lzu.edu.cn/hello.readelf

Okay, here's the entry for 'someint':

 <2><1ae9>: Abbrev Number: 32 (DW_TAG_formal_parameter)
     DW_AT_name        : someint	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 6	
     DW_AT_type        : <1b0b>	
     DW_AT_location    : 2 byte block: 91 8 	(DW_OP_fbreg: 8)

(Quick DWARF intro: the info is a tree; the first number in <angle
brackets> at the top is the nesting level, so each <2> is the child of
the most recent preceding <1>, etc.  The <1ae9> is the offset of this
entry in the debug data; entries point to others by their offset.  So
if you find the entry at <1b0b>, you'll find someint's type.)

DW_AT_location describes the variable's location, and it is using a
DWARF expression, as I guessed.  That's why the tracepoint code
dosen't know what to do with it.  It's a pretty simple expression,
though, and one that the existing dwarf2_tracepoint_var_ref code would
handle.

> If I write up thos functions (no idea yet how hard that will be and if I can
> actually do it), what would be the procedure to get these changes into GDB ?
> The tracepoint implementation I should do is intended for release under GPL
> so I would like to get it clean from the start.

The file gdb/CONTRIBUTE explains how to contribute to GDB.  The only
thing I'd add is that it's best to work against the current GDB
sources: http://sourceware.org/gdb/current/

I've also been finding quilt really handy for breaking a large patch
into small, separable units: http://savannah.nongnu.org/projects/quilt