Re: [PATCH] Add CTF support to GDB [3/4] ctf target

[Hui Zhu <teawater at gmail dot com>]

On Fri, Nov 30, 2012 at 4:46 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Hui" == Hui Zhu <hui_zhu@mentor.com> writes:
>
> Hui> It add a new target ctf like the tfile target to read the ctf file.
> Hui> After use this target open the ctf dir, you can use tfind to select
> Hui> the ctf event.  Each field inside this event will add to GDB as a
> Hui> internalvar.  And tdump will show all of them.  And you can use python
> Hui> read the value of them.
>
> Can you explain the internalvar feature a little?  Why is it needed?
> How are these variables named?  What do they represent?  Are they
> different from the saved trace data somehow?  I notice this feature
> isn't in the documentation at all -- I think that is required, perhaps
> with an example.
>
> Tom

Actually, I am not sure internalvar is the right name of the $xxx var.

About why is it needed?  This is a very good question.
Because CTF format is different with the tfile format and target ctf
is different with other target.

AFAIK each tracepoint frame entry in tfile format save the value of
var in address len format. Then when GDB want read the value of a var,
it will send address len info to "target tfile".

But CTF is different, it save the value of each var without address.
Libbabeltrace can parse this value out according to metadata file in
the CTF format dir.
Its advantage is to read this value don't need the debug info.  But
its weakness is not really fit with the GDB interace.
My first design is just support tfind to select the traceframe and
tdump to show all the value of the vars.  But it is not very useful
and cannot work very well with python.
So I change it to add each value to the GDB as a internalvar and named
as the name of var.
The python can access each var in the CTF for example: python print
int(gdb.parse_and_eval("$ret"))

I will update the doc of "target ctf" to add some example about use
this internalvar.

Thanks,
Hui