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

Marc Khouzam
2014-01-30T19:21:47Z

> -----Original Message-----
> From: Yao Qi [mailto:yao@codesourcery.com]
> Sent: Thursday, January 30, 2014 12:44 AM
> To: gdb-patches@sourceware.org
> Cc: Marc Khouzam
> Subject: [PATCH 0/2] Create inferior fro trace file target
>
> Marc reported that Eclipse is unable to load trace file with GDB 7.7, but it
> works with GDB 7.6. https://sourceware.org/ml/gdb/2014-
> 01/msg00031.html
> This change is caused by my patch:
>
> [RFC] Don't create inferior in tfile target.
> https://sourceware.org/ml/gdb-patches/2013-05/msg00068.html
>
> because I didn't think inferior should be created when a tracefile is loaded.
>
> On 01/30/2014 04:56 AM, Marc Khouzam wrote:
> > The trace file processing is based on the core file one, which shows
> > the execution tree after the core file is loaded.
> > But reading your mail makes me think that it makes sense that when
> > loading a trace file there would be no inferior or thread yet.
> > However, when selecting a trace record, then we would need to see the
> > inferior and thread. This is not the case with 7.7.
>
> I don't know why trace file processing is based on the core file. They are
> different, IMO.

When starting the debug session, for a user, it is very similar to ask
to look at a core file than to look at a trace file. So in Eclipse, it is
the same UI except that the user specifies if the file is a trace file
or a core file.

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

Eclipse fakes things a bit to make it look similar. Maybe that is not the best
way to go and I'll have to revisit that eventually.

> Anyway, it is not a good time to discuss about trace file format and how
> Eclipse should handle trace file. Let me focus on this problem and patches
> at first :).

Thank you.

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

I confirmed that things work again with Eclipse once I applied your patches.

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

You can guess where I place my vote :)

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

If you are asking about Eclipse, we don't support multi-target, so the problem
never presented itself. Maybe this should be part of a bigger discussion about
how trace files should be handled.

> *** BLURB HERE ***

(Out of curiosity, I've wondered why you have the above line in your patch posts.)

Thanks for your quick reply to the issue!

Marc

> Yao Qi (2):
> Create inferior for tfile target
> Create inferior for ctf target.
>
> gdb/ctf.c | 24 ++++++++++++++++++++++++
> gdb/testsuite/gdb.trace/report.exp | 7 ++++++-
> gdb/testsuite/gdb.trace/tfile.exp | 3 ---
> gdb/tracepoint.c | 19 +++++++++++++++++++
> 4 files changed, 49 insertions(+), 4 deletions(-)
>
> --
> 1.7.7.6