[00/10] Improve GDB/gdbserver experience when using a local gdbserver

  The goal of this series is to improve the user experience when using a
local (running on the same machine as GDB) gdbserver.

Outside of testing, there are still plenty of occasions when a user
can end up running gdbserver on the same machine as GDB, tools like
valgrind communicate via the remote protocol, as do many simulators
(other than those built into GDB).

This series includes the following improvements:

  1. Better handling of gdbserver's default executable and arguments.
  This applies to remote gdbservers and local gdbservers,

  2. Allow sysroot 'target:' prefix to be ignored when gdbserver is
  running locally to GDB, and

  3. Allow the user to skip setting 'remote exec-file' if gdbserver is
  running locally to GDB.

---

Andrew Burgess (10):
  gdb: have remote_target::extended_remote_run take the exec filename
  gdb: improve how 'remote exec-file' is stored and accessed
  gdb: improve show text and help text for 'remote exec-file'
  gdb/gdbserver: add new qDefaultExecAndArgs packet
  gdb: detect when gdbserver has no default executable set
  gdb: make use of is_target_filename
  gdb: add qMachineId packet
  gdb: remote filesystem can be local to GDB in some cases
  gdb: use exec_file with remote targets when possible
  gdb: remote the get_remote_exec_file function

 gdb/Makefile.in                               |   3 +
 gdb/NEWS                                      |  45 ++
 gdb/build-id.c                                |   2 +-
 gdb/configure.nat                             |   2 +-
 gdb/doc/gdb.texinfo                           | 160 ++++
 gdb/gdb_bfd.h                                 |   8 +
 gdb/linux-nat.c                               |  35 +
 gdb/nat/linux-machine-id.c                    |  60 ++
 gdb/nat/linux-machine-id.h                    |  44 ++
 gdb/remote-machine-id.c                       |  69 ++
 gdb/remote-machine-id.h                       | 108 +++
 gdb/remote.c                                  | 683 +++++++++++++++---
 gdb/testsuite/gdb.base/remote-exec-file.exp   |   7 +-
 gdb/testsuite/gdb.multi/gdb-settings.exp      |  13 +
 gdb/testsuite/gdb.server/ext-run.exp          | 131 +++-
 .../gdb.server/fetch-exec-and-args.c          |  34 +
 .../gdb.server/fetch-exec-and-args.exp        | 253 +++++++
 gdb/testsuite/gdb.server/server-local-fs.c    |  22 +
 gdb/testsuite/gdb.server/server-local-fs.exp  | 138 ++++
 gdb/testsuite/gdb.server/sysroot.exp          |  90 +--
 gdbserver/Makefile.in                         |   1 +
 gdbserver/configure.srv                       |   2 +-
 gdbserver/linux-low.cc                        |  19 +
 gdbserver/linux-low.h                         |   2 +
 gdbserver/server.cc                           |  47 ++
 gdbserver/target.cc                           |   8 +
 gdbserver/target.h                            |   9 +
 27 files changed, 1835 insertions(+), 160 deletions(-)
 create mode 100644 gdb/nat/linux-machine-id.c
 create mode 100644 gdb/nat/linux-machine-id.h
 create mode 100644 gdb/remote-machine-id.c
 create mode 100644 gdb/remote-machine-id.h
 create mode 100644 gdb/testsuite/gdb.server/fetch-exec-and-args.c
 create mode 100644 gdb/testsuite/gdb.server/fetch-exec-and-args.exp
 create mode 100644 gdb/testsuite/gdb.server/server-local-fs.c
 create mode 100644 gdb/testsuite/gdb.server/server-local-fs.exp


base-commit: a345d14fa65c2b69f2ba3abac8847b1c6a4dc656
  

On Wed, Aug 16, 2023 at 5:55 PM Andrew Burgess via Gdb-patches <
gdb-patches@sourceware.org> wrote:

> The goal of this series is to improve the user experience when using a
> local (running on the same machine as GDB) gdbserver.
>
> Outside of testing, there are still plenty of occasions when a user
> can end up running gdbserver on the same machine as GDB, tools like
> valgrind communicate via the remote protocol, as do many simulators
> (other than those built into GDB).
>
> This series includes the following improvements:
>
>   1. Better handling of gdbserver's default executable and arguments.
>   This applies to remote gdbservers and local gdbservers,
>
>   2. Allow sysroot 'target:' prefix to be ignored when gdbserver is
>   running locally to GDB, and
>
>   3. Allow the user to skip setting 'remote exec-file' if gdbserver is
>   running locally to GDB.
>
>
> I think the series is great, I'm really excited to see them. I especially
appreciate how this improves using GDB with Valgrind's vgdb --multi.
  

Hi Andrew,

On Wed, 2023-08-16 at 16:54 +0100, Andrew Burgess wrote:
> The goal of this series is to improve the user experience when using a
> local (running on the same machine as GDB) gdbserver.
> 
> Outside of testing, there are still plenty of occasions when a user
> can end up running gdbserver on the same machine as GDB, tools like
> valgrind communicate via the remote protocol, as do many simulators
> (other than those built into GDB).
> 
> This series includes the following improvements:
> 
>   1. Better handling of gdbserver's default executable and arguments.
>   This applies to remote gdbservers and local gdbservers,
> 
>   2. Allow sysroot 'target:' prefix to be ignored when gdbserver is
>   running locally to GDB, and
> 
>   3. Allow the user to skip setting 'remote exec-file' if gdbserver is
>   running locally to GDB.

I read through most of this patch series and created a trivial
qDefaultExecAndArgs for vgdb that just returns 'U' and it seems to work
just fine, no more setting of remote exec-file needed \o/
https://bugs.kde.org/show_bug.cgi?id=473687

I have to think a bit more about qMachineId.
There were also some opinions expressed in this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=30541

Thanks,

Mark
  

Mark Wielaard <mark@klomp.org> writes:

> Hi Andrew,
>
> On Wed, 2023-08-16 at 16:54 +0100, Andrew Burgess wrote:
>> The goal of this series is to improve the user experience when using a
>> local (running on the same machine as GDB) gdbserver.
>> 
>> Outside of testing, there are still plenty of occasions when a user
>> can end up running gdbserver on the same machine as GDB, tools like
>> valgrind communicate via the remote protocol, as do many simulators
>> (other than those built into GDB).
>> 
>> This series includes the following improvements:
>> 
>>   1. Better handling of gdbserver's default executable and arguments.
>>   This applies to remote gdbservers and local gdbservers,
>> 
>>   2. Allow sysroot 'target:' prefix to be ignored when gdbserver is
>>   running locally to GDB, and
>> 
>>   3. Allow the user to skip setting 'remote exec-file' if gdbserver is
>>   running locally to GDB.
>
> I read through most of this patch series and created a trivial
> qDefaultExecAndArgs for vgdb that just returns 'U' and it seems to work
> just fine, no more setting of remote exec-file needed \o/
> https://bugs.kde.org/show_bug.cgi?id=473687

Excellent.

> I have to think a bit more about qMachineId.
> There were also some opinions expressed in this bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30541

Thanks for the link.  I'd not read that.  I think the only thing I took
from that was that the boot-id that I'm currently using likely isn't
going to work w.r.t. containers -- but Thiago Jung Bauermann already
pointed that out.

We already have some container detection support (at least, I believe
that's what it's doing) in linux_nat_target::filesystem_is_local (), so
I'm hoping I can use something based off that to extend what I currently
have.

It's just testing it that's going to slow me down, but I hope to take
another pass at it soon.

Thanks,
Andrew