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: Pedro Alves <palves at redhat dot com>
- To: Gary Benson <gbenson 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: Tue, 09 Jun 2015 15:23:22 +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>
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?
>
> I've updated linux_mntns_access_fs to translate ENOSYS from setns
> into ENOTSUP, so neither native nor gdbserver will ever get ENOSYS
> from this code. From [1] ENOTSUP seems to be the perfect code for
> linux_mntns_{open_cloexec,unlink,readlink} to be returning:
Great, thanks.
> Thanks for hassling me about this, it took me a while to understand
> what you were saying.
Thanks for the patience and following through.
Thanks,
Pedro Alves