From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45132 invoked by alias); 5 Jun 2015 15:13:43 -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 45123 invoked by uid 89); 5 Jun 2015 15:13:42 -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; Fri, 05 Jun 2015 15:13:41 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 7A4502C7704 for ; Fri, 5 Jun 2015 15:13:40 +0000 (UTC) Received: from blade.nx (ovpn-116-63.ams2.redhat.com [10.36.116.63]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55FDdLD005829; Fri, 5 Jun 2015 11:13:40 -0400 Received: by blade.nx (Postfix, from userid 1000) id 02DEF26231E; Fri, 5 Jun 2015 16:13:38 +0100 (BST) Date: Fri, 05 Jun 2015 15:13:00 -0000 From: Gary Benson To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: [pushed] Move vgdb special case into remote_filesystem_is_local Message-ID: <20150605151338.GA31581@blade.nx> References: <1430146276-15606-1-git-send-email-gbenson@redhat.com> <55547C8B.5050000@redhat.com> <20150515090211.GA13085@blade.nx> <5555D94D.6020606@redhat.com> <20150515131915.GA22794@blade.nx> <555B1A20.5040802@redhat.com> <20150527095016.GA19722@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150527095016.GA19722@blade.nx> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00084.txt.bz2 Gary Benson wrote: > Pedro Alves wrote: > > On 05/15/2015 02:19 PM, Gary Benson wrote: > > > Pedro Alves wrote: > > > > When you say: > > > > > > > > gdb_bfd_open contained a special case to make vgdb work with > > > > "target:" sysroots, but the implementation meant that GDB > > > > would fall back to the local filesystem if *any* > > > > to_fileio_open method failed with ENOSYS for *any* reason. > > > > > > > > I'd prefer to get an example target for one of those "if *any* > > > > to_fileio_open ... *any* reason". I'd like to understand the > > > > real motivation for the change. Because otherwise I get to > > > > wonder why would we handle any other target that goes through > > > > this path differently. > > > > > > In what's upstream right now, the only path (I think) that you > > > can get to the point in gdb_bfd_open with the workaround is if > > > you're using a remote target that doesn't support file > > > retrieval. But, in the namespace-awareness series I posted, > > > target_fileio_open can fail with ENOSYS if setns is not > > > available. That's the reason I made the change. > > > > I'm still confused on that rationale, as it leaves one important > > detail out: when target_fileio_open fails with ENOSYS because > > setns is not available, I assume that gdb falls back to the local > > filesystem. But isn't that what should happen? > > > > After your patch, we'll issue remote_hostio_open from within > > remote_filesystem_is_local, and if the remote side doesn't support > > setns, we'll get ENOSYS to "open", and thus fallback to local > > anyway? > > I'm trying to catch the specific case that a) you're using a remote > target, b) that doesn't support file retrieval, and c) the user has > not set any sysroot. In that case the user is presumably using a > "remote" client that operates on the local filesystem... so GDB > should access the local filesystem. > > For any other target_fileio_open failures GDB should not continue. > For example, the user attaches to a process in a container, and that > process's executable is "/bin/bash". If GDB can't open /bin/bash > _in_that_container_ (because setns isn't implemented) then GDB > should not try to access /bin/bash in it's own container. They > might be different files. FWIW I've pushed the patch to move the special case, I'll address the other stuff with the mount namespaces series. Cheers, Gary -- http://gbenson.net/