From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40470 invoked by alias); 10 Jun 2015 09:01:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 40456 invoked by uid 89); 10 Jun 2015 09:01:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 10 Jun 2015 09:01:23 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1004B2CD856; Wed, 10 Jun 2015 09:01:22 +0000 (UTC) Received: from blade.nx (ovpn-116-112.ams2.redhat.com [10.36.116.112]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5A91L9P007662; Wed, 10 Jun 2015 05:01:21 -0400 Received: by blade.nx (Postfix, from userid 1000) id 94F3A26291F; Wed, 10 Jun 2015 10:01:20 +0100 (BST) Date: Wed, 10 Jun 2015 09:01:00 -0000 From: Gary Benson To: Pedro Alves Cc: gdb-patches@sourceware.org, Eli Zaretskii , Doug Evans , Iago =?iso-8859-1?Q?L=F3pez?= Galeiras Subject: Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver Message-ID: <20150610090120.GA17727@blade.nx> References: <1429186791-6867-1-git-send-email-gbenson@redhat.com> <1430395542-16017-9-git-send-email-gbenson@redhat.com> <555DF2EE.2030707@redhat.com> <20150609141118.GA29533@blade.nx> <5576F6DA.5030205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5576F6DA.5030205@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00168.txt.bz2 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/