[commit] Suggest newer gdbserver if it has no qXfer:exec-file:read

[Jan Kratochvil <jan.kratochvil@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On Tue, 05 Apr 2016 18:57:53 +0200, Pedro Alves wrote:
> On 03/23/2016 09:15 PM, Jan Kratochvil wrote:
> > I still do not see there any hint that a newer FSF gdbserver would also fix the
> > problem.
> 
> That's because I don't think it's a good approach.
> 
> If we followed that direction going forward, we'd end up with:
> 
>  warning: Remote gdbserver does not support determining executable automatically.
>  FSF gdbserver version 7.10 or later would support that.
>  warning: Remote gdbserver does not support foo.
>  FSF gdbserver version 6.5 or later would support that.
>  warning: Remote gdbserver does not support bar.
>  FSF gdbserver version 6.8 or later would support that.
> 
> Old version numbers shown on purpose -- that's what 7.10
> will feel like in a couple years.  I think it's not a good
> idea to show version numbers,

In mail
	[patch] Suggest newer gdbserver if it has no qXfer:exec-file:read
	https://sourceware.org/ml/gdb-patches/2016-03/msg00379.html
	Message-ID: <20160319201842.GA16540@host1.jankratochvil.net>
I was suggesting exactly one message (with one version number).

Only to get it through upon your request in mail
	Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read
	https://sourceware.org/ml/gdb-patches/2016-03/msg00487.html
	Message-ID: <20160323211547.GA17400@host1.jankratochvil.net>
there were two messages (but still one version number).

I never proposed any patch mentioning multiple versions which you claim now to
be a disadvantage of the patch of mine - that is exactly a straw man argument
case.


> nor am I convinced mentioning
> gdbserver is a good idea either.  There's bare metal targets, and
> then there's also other servers like qemu, Valgrind, RR, etc.
> 
> Sorry for pushing back, but I think warnings should be centered
> on features, not tools and versions.

That is technically the right approach but (I think) that does not work for
laypeople.  But I also think laypeople do not use (at least not directly) GDB
anyway so trying to make GDB userfriendly is probably a vain attempt
I sometimes try to do.


> This bit is OK.
+
> This bit is OK.  Please split them out and push them.

Checked in [attached].


Jan

[-- Attachment #2: Type: message/rfc822, Size: 4790 bytes --]

From: Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: [PATCH] Print the "file" command suggestion in exec_file_locate_attach
Date: Wed, 6 Apr 2016 15:57:08 +0200

currently:
	$ gdbserver-7.9 :1234 true &
	$ gdb -q -ex 'target remote :1234' # that -q is not relevant here
	Remote debugging using :1234
	warning: Could not load vsyscall page because no executable was specified
	try using the "file" command first.
	0x00007ffff7ddcc80 in ?? ()
	(gdb) b main
	No symbol table is loaded.  Use the "file" command.
	Make breakpoint pending on future shared library load? (y or [n]) _

Provide more suggestive message to use the "file" command.

gdb/ChangeLog
2016-04-06  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	* exec.c (exec_file_locate_attach): Print warning for unsupported
	target_pid_to_exec_file.
	* symfile-mem.c (add_vsyscall_page): Remove the "file" command
	message part.
---
 gdb/ChangeLog     |  8 ++++++++
 gdb/exec.c        |  8 +++++++-
 gdb/remote.c      | 27 +++++++++++++++++++++++++++
 gdb/symfile-mem.c |  3 +--
 4 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index fc9448d..c59249f 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,11 @@
+2016-04-06  Jan Kratochvil  <jan.kratochvil@redhat.com>
+	    Pedro Alves  <palves@redhat.com>
+
+	* exec.c (exec_file_locate_attach): Print warning for unsupported
+	target_pid_to_exec_file.
+	* symfile-mem.c (add_vsyscall_page): Remove the "file" command
+	message part.
+
 2016-04-04  Simon Marchi  <simon.marchi@ericsson.com>
 
 	* cli/cli-decode.c (help_cmd_list): Fix function doc and remove
diff --git a/gdb/exec.c b/gdb/exec.c
index 90811c0..a10ab9b 100644
--- a/gdb/exec.c
+++ b/gdb/exec.c
@@ -151,7 +151,13 @@ exec_file_locate_attach (int pid, int from_tty)
   /* Try to determine a filename from the process itself.  */
   exec_file = target_pid_to_exec_file (pid);
   if (exec_file == NULL)
-    return;
+    {
+      warning (_("No executable has been specified and target does not "
+		 "support\n"
+		 "determining executable automatically.  "
+		 "Try using the \"file\" command."));
+      return;
+    }
 
   /* If gdb_sysroot is not empty and the discovered filename
      is absolute then prefix the filename with gdb_sysroot.  */
diff --git a/gdb/remote.c b/gdb/remote.c
index 5c407b6..a88f4cd 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1496,6 +1496,15 @@ enum {
 
 static struct packet_config remote_protocol_packets[PACKET_MAX];
 
+/* gdbserver < 7.7 (before its fix from 2013-12-11) did reply to any
+   unknown 'v' packet with string "OK".  "OK" gets interpreted by GDB
+   as a reply to known packet.  For packet "vFile:setfs:" it is an
+   invalid reply and GDB would return error in
+   remote_hostio_set_filesystem, making remote files access impossible.
+   If this variable is non-zero it means the remote gdbserver is buggy
+   and any not yet detected packets are assumed as unsupported.  */
+static int unknown_v_replies_ok;
+
 /* Returns the packet's corresponding "set remote foo-packet" command
    state.  See struct packet_config for more details.  */
 
@@ -1519,6 +1528,9 @@ packet_config_support (struct packet_config *config)
     case AUTO_BOOLEAN_FALSE:
       return PACKET_DISABLE;
     case AUTO_BOOLEAN_AUTO:
+      if (unknown_v_replies_ok && config->name != NULL
+	  && config->name[0] == 'v')
+	return PACKET_DISABLE;
       return config->support;
     default:
       gdb_assert_not_reached (_("bad switch"));
@@ -4023,6 +4035,21 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
   if (packet_support (PACKET_QAllow) != PACKET_DISABLE)
     remote_set_permissions (target);
 
+  /* See unknown_v_replies_ok description.  */
+  {
+    const char v_mustreplyempty[] = "vMustReplyEmpty";
+
+    putpkt (v_mustreplyempty);
+    getpkt (&rs->buf, &rs->buf_size, 0);
+    if (strcmp (rs->buf, "OK") == 0)
+      unknown_v_replies_ok = 1;
+    else if (strcmp (rs->buf, "") == 0)
+      unknown_v_replies_ok = 0;
+    else
+      error (_("Remote replied unexpectedly to '%s': %s"), v_mustreplyempty,
+	     rs->buf);
+  }
+
   /* Next, we possibly activate noack mode.
 
      If the QStartNoAckMode packet configuration is set to AUTO,
diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
index 8eb5176..79739a6 100644
--- a/gdb/symfile-mem.c
+++ b/gdb/symfile-mem.c
@@ -214,8 +214,7 @@ add_vsyscall_page (struct target_ops *target, int from_tty)
 	  format should fix this.  */
 	{
 	  warning (_("Could not load vsyscall page "
-		     "because no executable was specified\n"
-		     "try using the \"file\" command first."));
+		     "because no executable was specified"));
 	  return;
 	}
       args.bfd = bfd;
-- 
2.5.5