From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30662 invoked by alias); 15 May 2015 11:32:33 -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 30649 invoked by uid 89); 15 May 2015 11:32:33 -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; Fri, 15 May 2015 11:32:32 +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 (8.14.4/8.14.4) with ESMTP id t4FBWUp0018453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 15 May 2015 07:32:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4FBWTeh018796; Fri, 15 May 2015 07:32:30 -0400 Message-ID: <5555D94D.6020606@redhat.com> Date: Fri, 15 May 2015 11:32: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> In-Reply-To: <20150515090211.GA13085@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00380.txt.bz2 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. Say for example, that gdb learns to open files from the remote target with "target mips" (remote-mips.c) as well, for remote stubs that support it. Seems like we'd handle ENOSYS the same way. I may be misunderstanding what you meant. In any case, I guess it does make more sense to move the checks to target_filesystem_is_local, so the target_filesystem_is_local() checks in core code get the right result before target_fileio_open is called (or target_fileio_readlink, etc.). But then the patch should be justified on those grounds. (Note that it's not correct to say that Valgrind _always_ works on the local filesystem. It's just more common to run Valgrind on the local machine, but one can well connect to a Valgrind running on a separate machine, even one of a different arch (e.g., an ARM GNU/Linux dev board). The fallback is really for any remote target that doesn't support file retrieval, and is needed because assuming local is a better default. I'd guess that qemu needs it too, for example.) Thanks, Pedro Alves