From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44961 invoked by alias); 29 Jul 2015 10:00:51 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 44952 invoked by uid 89); 29 Jul 2015 10:00:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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, 29 Jul 2015 10:00:49 +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 3EF1535419D; Wed, 29 Jul 2015 10:00:48 +0000 (UTC) Received: from blade.nx (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6TA0k17003921; Wed, 29 Jul 2015 06:00:47 -0400 Received: by blade.nx (Postfix, from userid 1000) id 4FF1A264F04; Wed, 29 Jul 2015 11:00:46 +0100 (BST) Date: Wed, 29 Jul 2015 10:00:00 -0000 From: Gary Benson To: Sandra Loosemore Cc: Pedro Alves , Paul_Koning@Dell.com, gdb@sourceware.org Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target Message-ID: <20150729100046.GA19548@blade.nx> References: <20150724085244.GB22673@blade.nx> <55B2444C.106@codesourcery.com> <2906903F-7478-4B9D-8A9A-A6256F8076EF@dell.com> <20150724151148.GA18553@blade.nx> <55B26267.4060905@redhat.com> <55B27348.1020104@codesourcery.com> <20150727121454.GA15226@blade.nx> <20150728092507.GA28545@blade.nx> <55B79DD6.1000200@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B79DD6.1000200@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00078.txt.bz2 Sandra Loosemore wrote: > On 07/28/2015 03:25 AM, Gary Benson wrote: > > Ok, here goes... > > > > * From a user's perspective GDB is magically prefixing *some* > > executable and shared library filenames with "target:". > > > > * From a developer's perspective this magic prefixing is implemented > > by having the string "target:" as the default sysroot. > > > > My proposal is to make the default sysroot be "" again, and add the > > prefix in solib_find_1 if certain conditions are met, specifically: > > > > * Executable filenames get prefixed with "target:" iff: > > Automatic "target:" prefixing is enabled > > AND gdb_sysroot is "" > > AND the filesystem is nonlocal > > > > * Shared library filenames get prefixed with "target:" iff: > > Automatic "target:" prefixing is enabled > > AND gdb_sysroot is "" > > AND the filesystem is nonlocal > > AND exec_filename starts with "target:" > > Can you explain what "the filesystem is nonlocal" means? Which > filesystem? Nonlocal relative to the host or the target? And what > qualifies as nonlocal -- e.g. are NFS or SSHFS mounts nonlocal? It refers to the method GDB must use to access inferior files. If GDB can access them using standard open/read/pread/write/unlink calls then the (inferior's) filesystem is local (to GDB). So NFS or SSHFS mounts are local in this sense. Remote targets have nonlocal filesystems because GDB must access them using special calls. Inferiors running in containers also have nonlocal filesystems because, even though the code is running on the same system, the inferior has a different filesystem. open("/usr/bin/python") in the inferior will get a different file to open("/usr/bin/python") in GDB. Cheers, Gary -- http://gbenson.net/