RFC: Do not try g-packet-guess algorithm on exited targets

RFC: Do not try g-packet-guess algorithm on exited targets

[Daniel Jacobowitz]

We got a bug report indicating that gdbserver --multi didn't work on
MIPS.  We'd connect to the target, try to read the XML description -
gdbserver reports an error because there's no process yet - and then
try to guess the description from the g packet length instead.  Of
course we can't do that; there's no process yet.

This patch fixes the problem.  We try qXfer on connection, then try
'g' only if (A) there was no XML description, and (B) there is a
running process, and (C) we are not in non-stop mode; assume that
non-stop targets can provide a description explicitly.

Pedro, could you take a look at this before I commit it?  Tested on
x86 with various local changes to make sure the new code was covered;
it fixes ext-attach.exp there.  I'll try it on MIPS now.

-- 
Daniel Jacobowitz
CodeSourcery

2008-11-23  Daniel Jacobowitz  <dan@codesourcery.com>

	PR gdb/2474
	* remote.c (remote_read_description_p): New function.
	(struct remote_state): New field tdesc_no_register_access.
	(remote_start_remote): Try to fetch the target description without
	any register access, then try with register access if the target
	is running.
	(remote_read_description): Honor tdesc_no_register_access.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.329
diff -u -p -r1.329 remote.c
--- remote.c	19 Nov 2008 14:45:09 -0000	1.329
+++ remote.c	23 Nov 2008 21:09:02 -0000
@@ -234,6 +234,8 @@ static void remote_async_get_pending_eve
 
 static void remote_terminal_ours (void);
 
+static int remote_read_description_p (struct target_ops *target);
+
 /* The non-stop remote protocol provisions for one pending stop reply.
    This is where we keep it until it is acknowledged.  */
 
@@ -303,6 +305,10 @@ struct remote_state
 
   /* True if the stub reports support for vCont;t.  */
   int support_vCont_t;
+
+  /* True if we are just connecting, and should not try fetching registers
+     yet.  */
+  int tdesc_no_register_access;
 };
 
 /* Returns true if the multi-process extensions are in effect.  */
@@ -2549,15 +2555,19 @@ remote_start_remote (struct ui_out *uiou
       getpkt (&rs->buf, &rs->buf_size, 0);
     }
 
+  /* Next, if the target can specify a description, read it.  We do
+     this before anything involving memory or registers.  At this
+     point, do not try to read registers from the target - it might
+     not be running, or it might be running and not stopped.  */
+  rs->tdesc_no_register_access = 1;
+  target_find_description ();
+  rs->tdesc_no_register_access = 0;
+
   /* On OSs where the list of libraries is global to all
      processes, we fetch them early.  */
   if (gdbarch_has_global_solist (target_gdbarch))
     solib_add (NULL, args->from_tty, args->target, auto_solib_add);
 
-  /* Next, if the target can specify a description, read it.  We do
-     this before anything involving memory or registers.  */
-  target_find_description ();
-
   if (non_stop)
     {
       if (!rs->non_stop_aware)
@@ -2643,6 +2653,17 @@ remote_start_remote (struct ui_out *uiou
 
       get_offsets ();		/* Get text, data & bss offsets.  */
 
+      /* If we could not find a description using qXfer, and we know
+	 how to do it some other way, try again.  This is not
+	 supported for non-stop; it could be, but it is tricky if
+	 there are no stopped threads when we connect.  */
+      if (remote_read_description_p (args->target)
+	  && gdbarch_target_desc (target_gdbarch) == NULL)
+	{
+	  target_clear_description ();
+	  target_find_description ();
+	}
+
       /* Use the previously fetched status.  */
       gdb_assert (wait_status != NULL);
       strcpy (rs->buf, wait_status);
@@ -7852,12 +7873,32 @@ register_remote_g_packet_guess (struct g
   VEC_safe_push (remote_g_packet_guess_s, data->guesses, &new_guess);
 }
 
+/* Return 1 if remote_read_description would do anything on this target
+   and architecture, 0 otherwise.  */
+
+static int
+remote_read_description_p (struct target_ops *target)
+{
+  struct remote_g_packet_data *data
+    = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
+
+  if (!VEC_empty (remote_g_packet_guess_s, data->guesses))
+    return 1;
+
+  return 0;
+}
+
 static const struct target_desc *
 remote_read_description (struct target_ops *target)
 {
+  struct remote_state *rs = get_remote_state ();
   struct remote_g_packet_data *data
     = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
 
+  /* Do not try this during initial connection.  */
+  if (rs->tdesc_no_register_access)
+    return NULL;
+
   if (!VEC_empty (remote_g_packet_guess_s, data->guesses))
     {
       struct remote_g_packet_guess *guess;

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Pedro Alves]

On Sunday 23 November 2008 21:14:54, Daniel Jacobowitz wrote:
>  static const struct target_desc *
>  remote_read_description (struct target_ops *target)
>  {
> +  struct remote_state *rs = get_remote_state ();
>    struct remote_g_packet_data *data
>      = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
>  
> +  /* Do not try this during initial connection.  */
> +  if (rs->tdesc_no_register_access)
> +    return NULL;
> +

Is this new flag working around that fact that remote_open_1 does this?

  /* Assume that the target is running, unless we learn otherwise.  */
  target_mark_running (target);

If we change the logic around to:

 /* Assume that the target is not running, unless we learn
     otherwise.  */
  if (extended_p)
    target_mark_exited (target);

Then would this in remote_read_description work instead of a
new flag?

> +  /* Do not try this during initial connection.  */
> +  if (!target_has_execution || ptid_equal (inferior_ptid, null_ptid))
> +    return NULL;

(or just null_ptid).

I've done that change locally just a few days ago because I found out
that the bit in remote_start_remote that does:

   if (gdbarch_has_global_solist (target_gdbarch))
     solib_add (NULL, args->from_tty, args->target, auto_solib_add);

also ended up trying to do things to a non-existant inferior due
to target_has_execution being true while that is a lie in the 
'extended-remote without an inferior yet' case.

-- 
Pedro Alves

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Daniel Jacobowitz]

On Sun, Nov 23, 2008 at 10:11:58PM +0000, Pedro Alves wrote:
> Is this new flag working around that fact that remote_open_1 does this?
> 
>   /* Assume that the target is running, unless we learn otherwise.  */
>   target_mark_running (target);

Right.

> Then would this in remote_read_description work instead of a
> new flag?
> 
> > +  /* Do not try this during initial connection.  */
> > +  if (!target_has_execution || ptid_equal (inferior_ptid, null_ptid))
> > +    return NULL;
> 
> (or just null_ptid).

It ought to.  Let me give that a try.

(The patch fixes 9 FAILs in gdb.server/\* on mips-linux, as expected.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Daniel Jacobowitz]

On Sun, Nov 23, 2008 at 10:11:58PM +0000, Pedro Alves wrote:
> If we change the logic around to:
> 
>  /* Assume that the target is not running, unless we learn
>      otherwise.  */
>   if (extended_p)
>     target_mark_exited (target);
> 
> Then would this in remote_read_description work instead of a
> new flag?

Like the attached?  It works in my testing and is much nicer.

I did have a question while looking at this.  We call
wait_for_inferior via start_remote when connecting to an all-stop
target, but not when connecting to a non-stop target.  Does this
work because non-stop is always async, and we push the stop replies to
be noticed by the main event loop?

-- 
Daniel Jacobowitz
CodeSourcery

2008-11-23  Daniel Jacobowitz  <dan@codesourcery.com>

	PR gdb/2474
	* remote.c (remote_read_description_p): New function.
	(remote_start_remote): Try to fetch the target description
	before adding shared libraries.  Try again later if the
	target is running but stopped.
	(remote_open_1): Mark extended targets as exited by default.
	(remote_read_description): Check target_has_execution.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.329
diff -u -p -r1.329 remote.c
--- remote.c	19 Nov 2008 14:45:09 -0000	1.329
+++ remote.c	24 Nov 2008 14:40:47 -0000
@@ -234,6 +234,8 @@ static void remote_async_get_pending_eve
 
 static void remote_terminal_ours (void);
 
+static int remote_read_description_p (struct target_ops *target);
+
 /* The non-stop remote protocol provisions for one pending stop reply.
    This is where we keep it until it is acknowledged.  */
 
@@ -2549,15 +2551,15 @@ remote_start_remote (struct ui_out *uiou
       getpkt (&rs->buf, &rs->buf_size, 0);
     }
 
+  /* Next, if the target can specify a description, read it.  We do
+     this before anything involving memory or registers.  */
+  target_find_description ();
+
   /* On OSs where the list of libraries is global to all
      processes, we fetch them early.  */
   if (gdbarch_has_global_solist (target_gdbarch))
     solib_add (NULL, args->from_tty, args->target, auto_solib_add);
 
-  /* Next, if the target can specify a description, read it.  We do
-     this before anything involving memory or registers.  */
-  target_find_description ();
-
   if (non_stop)
     {
       if (!rs->non_stop_aware)
@@ -2643,6 +2645,17 @@ remote_start_remote (struct ui_out *uiou
 
       get_offsets ();		/* Get text, data & bss offsets.  */
 
+      /* If we could not find a description using qXfer, and we know
+	 how to do it some other way, try again.  This is not
+	 supported for non-stop; it could be, but it is tricky if
+	 there are no stopped threads when we connect.  */
+      if (remote_read_description_p (args->target)
+	  && gdbarch_target_desc (target_gdbarch) == NULL)
+	{
+	  target_clear_description ();
+	  target_find_description ();
+	}
+
       /* Use the previously fetched status.  */
       gdb_assert (wait_status != NULL);
       strcpy (rs->buf, wait_status);
@@ -3163,8 +3176,9 @@ remote_open_1 (char *name, int from_tty,
     }
   push_target (target);		/* Switch to using remote target now.  */
 
-  /* Assume that the target is running, unless we learn otherwise.  */
-  target_mark_running (target);
+  /* Assume that the target is not running, until we learn otherwise.  */
+  if (extended_p)
+    target_mark_exited (target);
 
   /* Register extra event sources in the event loop.  */
   remote_async_inferior_event_token
@@ -7852,12 +7866,32 @@ register_remote_g_packet_guess (struct g
   VEC_safe_push (remote_g_packet_guess_s, data->guesses, &new_guess);
 }
 
+/* Return 1 if remote_read_description would do anything on this target
+   and architecture, 0 otherwise.  */
+
+static int
+remote_read_description_p (struct target_ops *target)
+{
+  struct remote_g_packet_data *data
+    = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
+
+  if (!VEC_empty (remote_g_packet_guess_s, data->guesses))
+    return 1;
+
+  return 0;
+}
+
 static const struct target_desc *
 remote_read_description (struct target_ops *target)
 {
   struct remote_g_packet_data *data
     = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
 
+  /* Do not try this during initial connection, when we do not know
+     whether there is a running but stopped thread.  */
+  if (!target_has_execution || ptid_equal (inferior_ptid, null_ptid))
+    return NULL;
+
   if (!VEC_empty (remote_g_packet_guess_s, data->guesses))
     {
       struct remote_g_packet_guess *guess;

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Pedro Alves]

On Monday 24 November 2008 14:48:21, Daniel Jacobowitz wrote:
> Like the attached?  It works in my testing and is much nicer.

Yep, looks good.

> I did have a question while looking at this.  We call
> wait_for_inferior via start_remote when connecting to an all-stop
> target, but not when connecting to a non-stop target.  Does this
> work because non-stop is always async, and we push the stop replies to
> be noticed by the main event loop?

Yes.

-- 
Pedro Alves

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Daniel Jacobowitz]

On Mon, Nov 24, 2008 at 02:58:47PM +0000, Pedro Alves wrote:
> On Monday 24 November 2008 14:48:21, Daniel Jacobowitz wrote:
> > Like the attached?  It works in my testing and is much nicer.
> 
> Yep, looks good.

Thanks, I checked it in.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Michael Snyder]

Daniel Jacobowitz wrote:
> We got a bug report indicating that gdbserver --multi didn't work on
> MIPS.  We'd connect to the target, try to read the XML description -
> gdbserver reports an error because there's no process yet - and then
> try to guess the description from the g packet length instead.  Of
> course we can't do that; there's no process yet.
> 
> This patch fixes the problem.  We try qXfer on connection, then try
> 'g' only if (A) there was no XML description, and (B) there is a
> running process, and (C) we are not in non-stop mode; assume that
> non-stop targets can provide a description explicitly.

Just curious -- how do you determine whether or not there is
a running process?

Re: RFC: Do not try g-packet-guess algorithm on exited targets

[Daniel Jacobowitz]

On Mon, Dec 01, 2008 at 02:07:50PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
>> We got a bug report indicating that gdbserver --multi didn't work on
>> MIPS.  We'd connect to the target, try to read the XML description -
>> gdbserver reports an error because there's no process yet - and then
>> try to guess the description from the g packet length instead.  Of
>> course we can't do that; there's no process yet.
>>
>> This patch fixes the problem.  We try qXfer on connection, then try
>> 'g' only if (A) there was no XML description, and (B) there is a
>> running process, and (C) we are not in non-stop mode; assume that
>> non-stop targets can provide a description explicitly.
>
> Just curious -- how do you determine whether or not there is
> a running process?

We send out a "?" and see what we get back.  If there's a process,
it's a stop reply; if there's nothing, we get the exit status of the
last process.

-- 
Daniel Jacobowitz
CodeSourcery