From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83611 invoked by alias); 19 May 2015 11:10:29 -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 83597 invoked by uid 89); 19 May 2015 11:10:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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; Tue, 19 May 2015 11:10:27 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 9EE638E774 for ; Tue, 19 May 2015 11:10:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4JBAP72007219; Tue, 19 May 2015 07:10:25 -0400 Message-ID: <555B1A20.5040802@redhat.com> Date: Tue, 19 May 2015 11:10:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gary Benson CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Move vgdb special case into remote_filesystem_is_local 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> In-Reply-To: <20150515131915.GA22794@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00470.txt.bz2 On 05/15/2015 02:19 PM, Gary Benson wrote: > Pedro Alves wrote: >> On 05/15/2015 10:02 AM, Gary Benson wrote: >>> Pedro Alves wrote: >>>> On 04/27/2015 03:51 PM, Gary Benson wrote: >>>>> Valgrind GDB (vgdb) presents itself as a remote target but >>>>> works on the local filesystem. 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. >>>> >>>> Can you give an example target where we'd want this to behave >>>> differently? >>>> >>>> E.g,. what should happen with "target sim" ? >>> >>> I don't understand what you're asking. "target sim" doesn't use >>> remote_filesystem_is_local, (to_filesystem_is_local for sim is the >>> default, tdefault_filesystem_is_local, which returns 1 always). >> >> 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. > > Ah, ok, I get what you're asking. > > 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? In any case, (I have yet to go read your v2 of that series), it sounds wrong suspicious to return ENOSYS for that case. ENOSYS would indicate that "open" is not implemented, but that doesn't sound like the case you have. "open" is indeed implemented, but it happens that it can't satisfy the requested path. Thus, something like EINVAL, EOPNOTSUPP or ENODEV may be more appropriate. As I said, I agree with moving the checks to target_filesystem_is_local time, but for a different rationale. Thanks, Pedro Alves