From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24377 invoked by alias); 28 Jul 2015 09:25:13 -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 24364 invoked by uid 89); 28 Jul 2015 09:25:12 -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; Tue, 28 Jul 2015 09:25:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 4DA72359A41; Tue, 28 Jul 2015 09:25:09 +0000 (UTC) Received: from blade.nx (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6S9P8su001833; Tue, 28 Jul 2015 05:25:08 -0400 Received: by blade.nx (Postfix, from userid 1000) id C92FC264EF9; Tue, 28 Jul 2015 10:25:07 +0100 (BST) Date: Tue, 28 Jul 2015 09:25:00 -0000 From: Gary Benson To: Pedro Alves Cc: Sandra Loosemore , Paul_Koning@Dell.com, gdb@sourceware.org Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target Message-ID: <20150728092507.GA28545@blade.nx> References: <55B1768E.9090309@codesourcery.com> <55B1A4FC.9010403@codesourcery.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150727121454.GA15226@blade.nx> X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00062.txt.bz2 Gary Benson wrote: > Sandra Loosemore wrote: > > On 07/24/2015 10:05 AM, Pedro Alves wrote: > > > On 07/24/2015 04:27 PM, Paul_Koning@Dell.com wrote: > > > > But having sysroot default to target is also a bad idea for lots > > > > of other people. Consider embedded systems: you presumably have > > > > stripped images there, but unstripped ones on your build host. > > > > > > But in that scenario, with the old default sysroot, how was gdb > > > finding the binaries on the build host? The binaries on the > > > equilalent locations on the host's root will certainly not match > > > the embedded/target system's. In that scenario, you must have > > > been pointing the "set sysroot" somewhere local? And if you do > > > that, nothing changes in 7.10, gdb will still access the files on > > > the local filesystem. > > > > > > From the discussion so far, it seems that the only case that ends > > > up regressing is the case where the host and target share both the > > > filesystem, and the host/target paths match. I don't know off > > > hand how to make gdb aware of that automatically. > > > > There's also the case where the host and target sysroot locations do > > not match at all. As I said, this used to work reasonably well for > > application debugging, where the user isn't interested in debugging > > shared libraries and doesn't care if the shared library symbol > > information isn't available to GDB. It used to print a helpful > > message suggesting using "set sysroot" if the user wants the shared > > library information, instead of hanging on startup with no > > indication of what the trouble is or how to fix it. I can't see the > > new default behavior as an improvement over the old. > > > > > That seems like enough of a special case that could well be > > > handled by an explicit "set sysroot /" in e.g., the toolchain's > > > system-gdbinit, or by building gdb with "--with-sysroot=/". > > > > There are a bunch of possible workarounds for this, but why can't we > > make GDB "just work" by default, as it used to, instead of requiring > > users to build GDB differently or install a workaround or issue > > extra commands manually that they didn't used to need at all? > > I have an idea for a solution to this. I should know in a few hours > if it can work. Tomorrow morning at the very latest. 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:" There's a new boolean here, "set auto-target-prefix on|off", which is enabled by default. So: gdb; target remote :9999 -> "target:" prefix applied gdb FILE; target remote :9999 -> no "target:" prefix The latter is how Sandra is invoking GDB. Also: gdb -n PID, and gdb; attach PID -> "target:" prefix applied iff FS is nonlocal Aside from the fact that this should fix Sandra's use case without breaking any I care about, I like that users doing non-remote, non- container debugging will not see "target:" prefixes onscreen unless they're actually necessary. Comments? Cheers, Gary -- http://gbenson.net/