From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87957 invoked by alias); 28 Jul 2015 21:27:58 -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 87936 invoked by uid 89); 28 Jul 2015 21:27:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Jul 2015 21:27:56 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1ZKCPg-0006l6-Eg from Don_Breazeal@mentor.com ; Tue, 28 Jul 2015 14:27:52 -0700 Received: from NA-MBX-04.mgc.mentorg.com ([169.254.4.176]) by SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) with mapi id 14.03.0224.002; Tue, 28 Jul 2015 14:27:52 -0700 From: "Breazeal, Don" To: SF Markus Elfring , "gdb@sourceware.org" Subject: RE: Debugging software including background processes Date: Tue, 28 Jul 2015 21:27:00 -0000 Message-ID: References: <55B7EB17.1080406@users.sourceforge.net> In-Reply-To: <55B7EB17.1080406@users.sourceforge.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg00072.txt.bz2 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZ2Ri LW93bmVyQHNvdXJjZXdhcmUub3JnIFttYWlsdG86Z2RiLW93bmVyQHNvdXJj ZXdhcmUub3JnXSBPbg0KPiBCZWhhbGYgT2YgU0YgTWFya3VzIEVsZnJpbmcN Cj4gU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAxNSAxOjUxIFBNDQo+IFRv OiBnZGJAc291cmNld2FyZS5vcmcNCj4gU3ViamVjdDogRGVidWdnaW5nIHNv ZnR3YXJlIGluY2x1ZGluZyBiYWNrZ3JvdW5kIHByb2Nlc3Nlcw0KPiANCj4g SGVsbG8sDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gZGVidWcgc3BlY2lmaWMg c29mdHdhcmUgb2NjYXNpb25hbGx5IHdoaWNoIHVzZXMgYWxzbw0KPiBiYWNr Z3JvdW5kIHByb2Nlc3NlcyAob24gbXkgb3BlblNVU0UgVHVtYmxld2VlZCBz eXN0ZW0pLg0KPiANCj4gKiBDYW4gdGhlIHRvb2wgImdkYiA3LjktMy4xIiBi ZSBjb25maWd1cmVkIHRvIHN0YXJ0IGRldGFpbGVkIGRlYnVnZ2luZw0KPiAg IGlmIGFub3RoZXIgYmFja2dyb3VuZCBwcm9jZXNzIHdpbGwgYmUgc3RhcnRl ZD8NCj4gDQo+ICogSG93IGNhbiBhIGNvcnJlc3BvbmRpbmcgYmFja3RyYWNl IGJlIGNvbGxlY3RlZCBhbmQgYW5hbHlzZWQgaWYgYQ0KPiBzdWJwcm9jZXNz DQo+ICAgbWlnaHQgaGF2ZSBmYWlsZWQgYnkgYSBzZWdtZW50YXRpb24gZmF1 bHQgZm9yIGV4YW1wbGU/DQoNCg0KTWFya3VzLA0KVGhlIEdEQiBtYW51YWwn cyBzZWN0aW9ucyBvbiBkZWJ1Z2dpbmcgZm9ya3MoaHR0cHM6Ly9zb3VyY2V3 YXJlLm9yZy9nZGIvb25saW5lZG9jcy9nZGIvRm9ya3MuaHRtbCkgYW5kIG9u IGRlYnVnZ2luZyBtdWx0aXBsZSBwcm9ncmFtcyAoaHR0cHM6Ly9zb3VyY2V3 YXJlLm9yZy9nZGIvb25saW5lZG9jcy9nZGIvSW5mZXJpb3JzLWFuZC1Qcm9n cmFtcy5odG1sI0luZmVyaW9ycy1hbmQtUHJvZ3JhbXMpIHNob3VsZCBoZWxw IHdpdGggdGhpcy4gIFRoZSBMaW51eCBjb3JlKDUpIG1hbiBwYWdlIGhhcyBp bmZvcm1hdGlvbiBvbiBuYW1pbmcgY29yZSBmaWxlcyB0aGF0IG1pZ2h0IGFs c28gaGVscC4NCi0tRG9uDQo= >From gdb-return-44565-listarch-gdb=sources.redhat.com@sourceware.org Tue Jul 28 22:12:08 2015 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 96951 invoked by alias); 28 Jul 2015 22:12:08 -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 Delivered-To: mailing list gdb@sourceware.org Received: (qmail 96937 invoked by uid 89); 28 Jul 2015 22:12:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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 22:12:06 +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 4585A344F5B; Tue, 28 Jul 2015 22:12:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6SMC2Q8008194; Tue, 28 Jul 2015 18:12:03 -0400 Message-ID: <55B7FE32.1000506@redhat.com> Date: Tue, 28 Jul 2015 22:12: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 CC: gbenson@redhat.com, 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> <55B26267.4060905@redhat.com> <75C87584-1A46-435F-A8AF-F7D827CE9793@dell.com> In-Reply-To: <75C87584-1A46-435F-A8AF-F7D827CE9793@dell.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2015-07/txt/msg00073.txt.bz2 Content-length: 2685 On 07/24/2015 05:58 PM, Paul_Koning@Dell.com wrote: > >> On Jul 24, 2015, at 12:05 PM, 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. >> >> 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=/“. > > If you’re doing cross-builds, then yes, you’d have a non-default sysroot. But if the host and target are the same OS, but the target has a small local file system with stripped images on it, then the default sysroot was valid in the past, but the new default is not. And in case the host and target are the same OS, but the binaries are of different versions (which happens frequently, machines don't usually update their packages at exactly the same time), then the default is almost right, but then the user gets misleading backtraces. It seems to me like if you take the trouble to build such a setup as you suggest, putting a "set sysroot /" somewhere is just another small setup step. The idea of the new default was both what's more convenient in the wider set of use cases and also picking correctness over efficiency, while still letting the user point at local copies of files (or set sysroot /dev/null to point nowhere, for e.g.) to get efficiency back, when possible. The discoverability of the need to do the latter I believe should be treated as a separate matter, which seems could be resolved with a warning around "warning: fetching files from the target. Use "set sysroot" to point at local copies for faster access." or some such, as has already been suggested elsewhere. IOW, if we had that already, how bad would it really be if target: remains the default? Thanks, Pedro Alves