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

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

[Yao Qi]

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.

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

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

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

*** BLURB HERE ***

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

[PATCH 1/2] Create inferior for tfile target

[Yao Qi]

When a trace file is loaded in Eclipse, it is expected to see thread
and process (=thread-group-started and =thread-created).  Create an
inferior and add a thread for this purpose.

This patch just reverts my previous patch.

gdb/testsuite:

2014-01-30  Yao Qi  <yao@codesourcery.com>

	Revert this patch:

	2013-05-24  Yao Qi  <yao@codesourcery.com>

	* gdb.trace/tfile.exp: Test inferior and thread.

gdb:

2014-01-30  Yao Qi  <yao@codesourcery.com>

	Revert this patch:

	2013-05-24  Yao Qi  <yao@codesourcery.com>

	* tracepoint.c (TFILE_PID): Remove.
	(tfile_open): Don't add thread and inferior.
	(tfile_close): Don't set 'inferior_ptid'.  Don't call
	exit_inferior_silent.
	(tfile_thread_alive): Remove.
	(init_tfile_ops): Don't set field 'to_thread_alive' of
	tfile_ops.
---
 gdb/testsuite/gdb.trace/tfile.exp |    3 ---
 gdb/tracepoint.c                  |   19 +++++++++++++++++++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.trace/tfile.exp b/gdb/testsuite/gdb.trace/tfile.exp
index 35d9c2c..634c2fc 100644
--- a/gdb/testsuite/gdb.trace/tfile.exp
+++ b/gdb/testsuite/gdb.trace/tfile.exp
@@ -136,9 +136,6 @@ Trace buffer has 256 bytes of 4096 bytes free \\(93% full\\).*
 Not looking at any trace frame.*" \
     "tstatus on error trace file"
 
-gdb_test "info threads" "No threads\..*"
-gdb_test "info inferiors" "\\* 1    <null>\[ \t\]+${binfile}.*"
-
 # Make sure we can reopen without error.
 gdb_test \
     "interpreter-exec mi \"-target-select tfile $tfile_basic\"" \
diff --git a/gdb/tracepoint.c b/gdb/tracepoint.c
index f3b9bfc..0a50606 100644
--- a/gdb/tracepoint.c
+++ b/gdb/tracepoint.c
@@ -79,6 +79,8 @@
    large.  (400 - 31)/2 == 184 */
 #define MAX_AGENT_EXPR_LEN	184
 
+#define TFILE_PID (1)
+
 /* A hook used to notify the UI of tracepoint operations.  */
 
 void (*deprecated_trace_find_hook) (char *arg, int from_tty);
@@ -4372,6 +4374,10 @@ tfile_open (char *filename, int from_tty)
       throw_exception (ex);
     }
 
+  inferior_appeared (current_inferior (), TFILE_PID);
+  inferior_ptid = pid_to_ptid (TFILE_PID);
+  add_thread_silent (inferior_ptid);
+
   if (ts->traceframe_count <= 0)
     warning (_("No traceframes present in this file."));
 
@@ -4382,6 +4388,8 @@ tfile_open (char *filename, int from_tty)
   merge_uploaded_trace_state_variables (&uploaded_tsvs);
 
   merge_uploaded_tracepoints (&uploaded_tps);
+
+  post_create_inferior (&tfile_ops, from_tty);
 }
 
 /* Interpret the given line from the definitions part of the trace
@@ -4754,6 +4762,10 @@ tfile_close (void)
   if (trace_fd < 0)
     return;
 
+  pid = ptid_get_pid (inferior_ptid);
+  inferior_ptid = null_ptid;	/* Avoid confusion from thread stuff.  */
+  exit_inferior_silent (pid);
+
   close (trace_fd);
   trace_fd = -1;
   xfree (trace_filename);
@@ -5250,6 +5262,12 @@ tfile_has_registers (struct target_ops *ops)
   return traceframe_number != -1;
 }
 
+static int
+tfile_thread_alive (struct target_ops *ops, ptid_t ptid)
+{
+  return 1;
+}
+
 /* Callback for traceframe_walk_blocks.  Builds a traceframe_info
    object for the tfile target's current traceframe.  */
 
@@ -5336,6 +5354,7 @@ init_tfile_ops (void)
   tfile_ops.to_has_stack = tfile_has_stack;
   tfile_ops.to_has_registers = tfile_has_registers;
   tfile_ops.to_traceframe_info = tfile_traceframe_info;
+  tfile_ops.to_thread_alive = tfile_thread_alive;
   tfile_ops.to_magic = OPS_MAGIC;
 }
 
-- 
1.7.7.6

[PATCH 2/2] Create inferior for ctf target.

[Yao Qi]

This patch creates inferior when GDB opens a ctf trace data, to be
consistent with tfile target.  A test case is added to test for
live target, tfile and ctf target.

gdb:

2014-01-30  Yao Qi  <yao@codesourcery.com>

	* ctf.c: Include "inferior.h" and "gdbthread.h".
	(CTF_PID): A new macro.
	(ctf_open): Call inferior_appeared and add_thread_silent.
	(ctf_close): Call exit_inferior_silent and set inferior_ptid.
	(ctf_thread_alive): New function.
	(init_ctf_ops): Install ctf_thread_alive to to_thread_alive.

gdb/testsuite:

2014-01-30  Yao Qi  <yao@codesourcery.com>

	* gdb.trace/report.exp (use_collected_data): Test the output
	of "info threads" and "info inferiors".
---
 gdb/ctf.c                          |   24 ++++++++++++++++++++++++
 gdb/testsuite/gdb.trace/report.exp |    7 ++++++-
 2 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/gdb/ctf.c b/gdb/ctf.c
index a22937f..6035c2b 100644
--- a/gdb/ctf.c
+++ b/gdb/ctf.c
@@ -26,6 +26,8 @@
 #include <sys/stat.h>
 #include "exec.h"
 #include "completer.h"
+#include "inferior.h"
+#include "gdbthread.h"
 
 #include <ctype.h>
 
@@ -76,6 +78,8 @@
 #define CTF_EVENT_ID_TSV_DEF 5
 #define CTF_EVENT_ID_TP_DEF 6
 
+#define CTF_PID (2)
+
 /* The state kept while writing the CTF datastream file.  */
 
 struct trace_write_handler
@@ -1188,6 +1192,10 @@ ctf_open (char *dirname, int from_tty)
   trace_dirname = xstrdup (dirname);
   push_target (&ctf_ops);
 
+  inferior_appeared (current_inferior (), CTF_PID);
+  inferior_ptid = pid_to_ptid (CTF_PID);
+  add_thread_silent (inferior_ptid);
+
   merge_uploaded_trace_state_variables (&uploaded_tsvs);
   merge_uploaded_tracepoints (&uploaded_tps);
 }
@@ -1198,10 +1206,16 @@ ctf_open (char *dirname, int from_tty)
 static void
 ctf_close (void)
 {
+  int pid;
+
   ctf_destroy ();
   xfree (trace_dirname);
   trace_dirname = NULL;
 
+  pid = ptid_get_pid (inferior_ptid);
+  inferior_ptid = null_ptid;	/* Avoid confusion from thread stuff.  */
+  exit_inferior_silent (pid);
+
   trace_reset_local_state ();
 }
 
@@ -1725,6 +1739,15 @@ ctf_has_registers (struct target_ops *ops)
   return get_traceframe_number () != -1;
 }
 
+/* This is the implementation of target_ops method to_thread_alive.
+   CTF trace data has one thread faked by GDB.  */
+
+static int
+ctf_thread_alive (struct target_ops *ops, ptid_t ptid)
+{
+  return 1;
+}
+
 /* This is the implementation of target_ops method to_traceframe_info.
    Iterate the events whose name is "memory", in current
    frame, extract memory range information, and return them in
@@ -1831,6 +1854,7 @@ Specify the filename of the CTF directory.";
   ctf_ops.to_has_stack = ctf_has_stack;
   ctf_ops.to_has_registers = ctf_has_registers;
   ctf_ops.to_traceframe_info = ctf_traceframe_info;
+  ctf_ops.to_thread_alive = ctf_thread_alive;
   ctf_ops.to_magic = OPS_MAGIC;
 }
 
diff --git a/gdb/testsuite/gdb.trace/report.exp b/gdb/testsuite/gdb.trace/report.exp
index 8bf1251..4d33512 100644
--- a/gdb/testsuite/gdb.trace/report.exp
+++ b/gdb/testsuite/gdb.trace/report.exp
@@ -197,7 +197,7 @@ proc use_collected_data { data_source } {
 	global tdp1 tdp2 tdp3 tdp4 tdp5 tdp6
 	global testline1 testline2 testline3 testline4 testline5 testline6
 	global pcreg fpreg spreg
-	global srcfile srcdir subdir
+	global srcfile srcdir subdir binfile
 	global arg1 arg3
 	global decimal hex gdb_prompt
 	#
@@ -397,6 +397,11 @@ proc use_collected_data { data_source } {
 		}
 	    }
 	}
+
+	# There is always a thread of an inferior, either a live one or
+	# a faked one.
+	gdb_test "info threads" "\\* ${decimal}    (process|Thread) ${decimal}\[ \t\].*"
+	gdb_test "info inferiors" "\\* 1    process ${decimal} \[ \t\]+${binfile}.*"
     }
 }
 
-- 
1.7.7.6

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

[Marc Khouzam]

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

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

[Yao Qi]

On 01/31/2014 03:21 AM, Marc Khouzam wrote:
> 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.
> 

Hmmm, that makes sense to me.

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

I meant these patches bring potential problems to multi-target
transition.  We (GDB folks) will revisit them when we go there.

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

It is part of the cover letter of this patch series, generated by
'git format-patch --cover-letter'.

-- 
Yao (齐尧)

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

[Pedro Alves]

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

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

[Marc Khouzam]

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

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

[Pedro Alves]

On 02/04/2014 09:08 PM, Marc Khouzam wrote:
>> > 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...

Even better.  :-)  Thanks a bunch.

-- 
Pedro Alves

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

[Joel Brobecker]

Thanks for the quick review, Pedro.

Once the patches are in, we should be able to produce the release!

-- 
Joel

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

[Yao Qi]

On 02/05/2014 04:57 AM, Pedro Alves wrote:

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

I don't have any questions to the model in this case, however, I don't
understand why Eclipse thinks "there must be a PID in the GDB trace
file".  Since Eclipse behaves in this way for a while, I have to accept
that.

> We've moved in the direction of "always a thread" a while ago,

What is "always a thread"?  Can you elaborate?

> 
> 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 for the review.  Two patches are pushed to both mainline and 7.7
branch.

-- 
Yao (齐尧)

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

[Joel Brobecker]

> > We've moved in the direction of "always a thread" a while ago,
> 
> What is "always a thread"?  Can you elaborate?

This was a change where even non-threaded programs would have
a thread.

> > 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 for the review.  Two patches are pushed to both mainline and 7.7
> branch.

Thanks! I will create the release tomorrow morning!

-- 
Joel

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

[Pedro Alves]

On 02/05/2014 12:15 PM, Yao Qi wrote:
>> > We've moved in the direction of "always a thread" a while ago,
> What is "always a thread"?  Can you elaborate?

"info threads" used to come out empty until a second thread
showed up.

Here's 6.8 debugging a single-threaded program:

 (gdb) info threads
 (gdb) info program
         Using the running image of child process 12775.
 Program stopped at 0x4004cf.
 It stopped at a breakpoint that has since been deleted.
 (gdb)

vs 7.0/current mainline:

 (gdb) info threads
   Id   Target Id         Frame
 * 1    process 12748 "main" main (argc=1, argv=0x7fffffffdb18) at main.c:5
 (gdb)

Basically, GDB nowadays models non-threaded programs as single-threaded
programs.  Thus "always a(t least one) thread".

-- 
Pedro Alves

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

[Mark Kettenis]

> Date: Wed, 5 Feb 2014 20:15:05 +0800
> From: Yao Qi <yao@codesourcery.com>
> 
> On 02/05/2014 04:57 AM, Pedro Alves wrote:
> 
> > We've moved in the direction of "always a thread" a while ago,
> 
> What is "always a thread"?  Can you elaborate?

In the old model we only used to build a list of threads if the
process was actually multi-threaded (or at least linked to a known
threads library).  The new "always a thread" model builds that list
(with a single entry) for non-threaded processes as well.