Re: [PATCH 0/2] Create inferior fro trace file target

[Pedro Alves <palves at redhat dot com>]

On 01/30/2014 05:44 AM, Yao Qi wrote:

>> To me, trace records are like a limited core file:
>> a snapshot of a specific point of the execution.  So, when looking
>> at a trace record, just like when looking at a core file, we want
>> to show the execution hierarchy, i.e., the process and thread
>> where the record was collected.
> 
> The corefile has information about thread and process, but trace file
> doesn't.  Thread and process is not mentioned in the "Trace File Format"
> doc https://sourceware.org/gdb/current/onlinedocs/gdb/Trace-File-Format.html

I agree with Marc here, in that looking at a traceframe is like
looking at a corefile.  I don't think he is implying that the code
is similar.  Only that a corefile is a snapshot of the program at
a given point in time, and so is a traceframe.  It just happens
that the traceframe often doesn't include the contents of all
of the inferior's memory, but so can a core -- e.g. we
print <unavailable> when printing memory/registers of trimmed
core files too.

> Keeping trace file similar to core file is unspecified, and their code
> are total independent to each other.  It is not good for Eclipse to
> assume that, unless we can extend trace file format to include the
> process id and the thread id in each trace frame.

I think the availability of the specific process id and thread ids
is a bit orthogonal to GDB modelling the existence of
processes/threads or not.  We can always say that "there's a process,
but we don't know its PID".  In fact, we do that for cores too.
That's the real question -- what model makes sense.

In any case, it makes sense to me to say that inferior foo has
been bound to some kind of execution object, like in the old:

 =thread-group-started

Here we have to read "thread-group" in MI as "inferior".  The
thread-group is a concept pre-dates "info inferiors", and can
be seen as sort of a misnomer.

> Reverting my patch works, which is included in patch 1/2.
> In patch 2/2, I add something similar to ctf target, and a test case.
> Patches are regression tested on x86_64-linux.  They are also tested
> on x86-linux with babeltrace installed.
> 
> In short, Eclipse replies on an undocumented GDB behavior, that GDB
> should provide inferior and thread when reading a trace file while  I
> don't think GDB has to.  If global maintainers think GDB 7.7 shouldn't
> break Eclipse, then we should pick these two patches up.
> 
> These two patches bring an issue for multi-target support, say if GDB
> opens two trace files in two targets, what is the expected output of
> "info inferiors" and "info threads"?

We've moved in the direction of "always a thread" a while ago,
so in the current model, both tfiles would be listed in the latter
command (but we can always revisit that once we get to multi-target).
As for "info inferiors", seems to me the tfiles should both be listed
somehow irrespective of the process/thread model.

In any case, both patches look OK to me, and I agree it's best to
avoid breaking Eclipse since we don't have a really good reason to
change behavior compared to previous releases right now.  So, OK
for both.  Thanks for fixing this.

We've talked about setting up a build bot in the gcc compile farm.
If that goes forward, it'd be great if we had some sort of
Eclipse + mainline GDB auto testing setup there as well.  Marc,
OOC, can the Eclipse+gdb testsuite run unattended?

-- 
Pedro Alves