From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95301 invoked by alias); 24 Jul 2015 16:36:40 -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 94405 invoked by uid 89); 24 Jul 2015 16:36:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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; Fri, 24 Jul 2015 16:36:38 +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 A824919F963; Fri, 24 Jul 2015 16:36:37 +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 t6OG60St010957; Fri, 24 Jul 2015 12:06:00 -0400 Message-ID: <55B26267.4060905@redhat.com> Date: Fri, 24 Jul 2015 16:36: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: Paul_Koning@Dell.com, gbenson@redhat.com CC: sandra@codesourcery.com, gdb@sourceware.org Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00049.txt.bz2 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. 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=/". Thanks, Pedro Alves