This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver
- From: Gary Benson <gbenson at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Eli Zaretskii <eliz at gnu dot org>, Doug Evans <dje at google dot com>, Iago López Galeiras <iago at endocode dot com>
- Date: Wed, 10 Jun 2015 10:01:20 +0100
- Subject: Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1429186791-6867-1-git-send-email-gbenson at redhat dot com> <1430395542-16017-9-git-send-email-gbenson at redhat dot com> <555DF2EE dot 2030707 at redhat dot com> <20150609141118 dot GA29533 at blade dot nx> <5576F6DA dot 5030205 at redhat dot com>
Pedro Alves wrote:
> On 06/09/2015 03:11 PM, Gary Benson wrote:
> > Pedro Alves wrote:
> > > For the setns/ENOSYS case, how about somehow probing whether
> > > setns actually works here (with a new method, or probing one
> > > of the existing ones with getpid()) and return empty packet,
> > > instead of ending up with open failing with ENOSYS later on?
> >
> > Probing and then telling GDB we don't understand "vFile:setfs:"
> > isn't that good of an idea. If we do that with an inferior in
> > another mount namespace then the end result is that gdbserver will
> > access the wrong filesystem. You might get "file not found", or
> > you might get an open filehandle on another file (i.e. the file
> > with the same name but in gdbserver's filesystem). If the
> > inferior's filesystem is different from gdbserver and gdbserver
> > cannot access that filesystem then the only correct response is
> > to fail.
>
> If the running system does not support "setfs", because it fails
> setns with ENOSYS, meaning, the system call isn't implemented at
> all, how can one end up in the situation that an inferior on the
> same kernel is running in a different filesystem namespace?
If the running kernel has namespaces support but GDB and/or glibc
was built on a kernel without. It's an edge case but it's possible.
Cheers,
Gary
--
http://gbenson.net/