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

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Tuesday, February 04, 2014 3:57 PM
> To: Yao Qi
> Cc: gdb-patches@sourceware.org; Marc Khouzam
> Subject: Re: [PATCH 0/2] Create inferior fro trace file target
> 
> 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.ht
> > ml
> 
> 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.

Thanks Pedro.
And thanks to Yao for the quick patches.

> 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?

Sure.  In fact, it is on my to-do-list to enable those tests at Eclipse.org.
It has taken longer than expected because we run the suite against
each of GDB 6.6 to GDB 7.6 (soon 7.7), so the setup is a little more complex.
It should be up soon...

Marc