Re: [PATCH 0/2] Use gdb_sysroot for main executable on attach

[Gary Benson <gbenson@redhat.com>]

Mark Kettenis wrote:
> > From: Gary Benson <gbenson@redhat.com>
> > 
> > This series modifies GDB to prefix the main executable's path with
> > gdb_sysroot under certain circumstances, namely:
> > 
> >  * The path supplied by target_pid_to_exec_file is absolute, and
> >  * gdb_sysroot is set and not remote.
> > 
> > This logic is skipped for remote gdb_sysroots because the subsequent
> > code does not support opening the main executable over the remote
> > protocol.  This is something I intend to rectify with future patches
> > but the ability to use gdb_sysroot like this is useful for attaching
> > to processes running in chroot jails and containerized environments
> > so I am submitting this series independently.
> 
> What problem are you trying to fix?

I'm mostly trying to eliminate the extra work users have to do in
order to attach to remote processes or to attach to local processes
running in containers.

For remote processes you have to do something like:

  set sysroot remote:
  file /path/to/local/copy/of/binary
  target remote WHEREVER

or:
  
  set sysroot /path/to/local/copy
  file /path/to/local/copy/of/binary
  target remote WHEREVER

I would ideally like to get to the situation where the only command
you need is "target remote ...", but a step in that direction is
removing the required "file" command.

For processes running in containers you have to do something like:

  set sysroot /proc/PID/root
  file /proc/PID/exe
  attach PID

Again, I'd like to get to the situation where the only command you
need is "attach PID".  This series removes the need for the "file"
command in this sequence, but you still need the "set sysroot".

For the ultimate solution (removing the need for "set sysroot")
Pedro suggested a new option, "set sysroot target:" that would be
the default and would mean "if the target is remote, pull binaries
over the remote protocol; if the target is local, grab them from
the filesystem."  There's details here:

  https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity

Aside from removing the need for the user to set a sysroot for
these two cases (where GDB has enough information to imply what
the user is asking for) it unblocks multi-inferior debugging
when different inferiors require different sysroots, something
that can't be done right now.  I don't think this is relevant
for remote debugging right now as we only support one gdbserver
connection at a time, but it is relevant for containers where
you might need to debug, eg, a webserver in one container
talking to a database server in another.

I would also like to make it possible to fetch stripped debug
info over the remote protocol if the user desires it, so that's
something else I'm thinking about with this work.

Cheers,
Gary

-- 
http://gbenson.net/