From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6491 invoked by alias); 17 Aug 2015 07:23:12 -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 6473 invoked by uid 89); 17 Aug 2015 07:23:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Aug 2015 07:23:10 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 17 Aug 2015 00:23:10 -0700 X-ExtLoop1: 1 Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga002.jf.intel.com with ESMTP; 17 Aug 2015 00:23:07 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.131]) by IRSMSX151.ger.corp.intel.com ([169.254.4.151]) with mapi id 14.03.0224.002; Mon, 17 Aug 2015 08:23:07 +0100 From: "Metzger, Markus T" To: Doug Evans CC: Pedro Alves , gdb-patches Subject: RE: [rfc] btrace: change record instruction-history /m Date: Mon, 17 Aug 2015 07:23:00 -0000 Message-ID: References: <1439552272-6256-1-git-send-email-markus.t.metzger@intel.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00415.txt.bz2 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3VnIEV2 YW5zIFttYWlsdG86ZGplQGdvb2dsZS5jb21dDQo+IFNlbnQ6IEZyaWRheSwg QXVndXN0IDE0LCAyMDE1IDc6MDIgUE0NCj4gVG86IE1ldHpnZXIsIE1hcmt1 cyBUDQo+IENjOiBQZWRybyBBbHZlczsgZ2RiLXBhdGNoZXMNCj4gU3ViamVj dDogUmU6IFtyZmNdIGJ0cmFjZTogY2hhbmdlIHJlY29yZCBpbnN0cnVjdGlv bi1oaXN0b3J5IC9tDQoNCg0KPiA+IEFsdGVybmF0aXZlbHksIHdlIGNvdWxk IGV4dGVuZCBEb3VnIEV2YW4ncyBuZXcgYWxnb3JpdGhtDQo+ID4gaHR0cHM6 Ly9zb3VyY2V3YXJlLm9yZy9tbC9nZGItcGF0Y2hlcy8yMDE1LTA4L21zZzAw MzM1Lmh0bWwgdG8gdGFrZSBhDQo+IHZlY3Rvcg0KPiA+IG9mIFBDcy4NCj4g Pg0KPiA+IDIwMTUtMDgtMTQgIE1hcmt1cyBNZXR6Z2VyIDxtYXJrdXMudC5t ZXR6Z2VyQGludGVsLmNvbT4NCj4gPg0KPiA+IGdkYi8NCj4gPiAgICAgICAg ICogcmVjb3JkLWJ0cmFjZS5jIChzdHJ1Y3QgYnRyYWNlX2xpbmVfcmFuZ2Up OiBOZXcuDQo+ID4gICAgICAgICAoYnRyYWNlX21rX2xpbmVfcmFuZ2UsIGJ0 cmFjZV9saW5lX3JhbmdlX2FkZCkNCj4gPiAgICAgICAgIChidHJhY2VfbGlu ZV9yYW5nZV9pc19lbXB0eSwgYnRyYWNlX2xpbmVfcmFuZ2VfY29udGFpbnNf cmFuZ2UpDQo+ID4gICAgICAgICAoYnRyYWNlX2ZpbmRfbGluZV9yYW5nZSwg YnRyYWNlX3ByaW50X2xpbmVzKTogTmV3Lg0KPiA+ICAgICAgICAgKGJ0cmFj ZV9pbnNuX2hpc3RvcnkpOiBBZGQgc291cmNlIGludGVybGVhdmluZyBhbGdv cml0aG0uDQo+IA0KPiBZZWFoLCBJJ2QgbGlrZSB0byBhdm9pZCBoYXZpbmcg bXVsdGlwbGUgY29waWVzIG9mIGNvZGUNCj4gZG9pbmcgYmFzaWNhbGx5IHRo ZSBzYW1lIHRoaW5nLg0KPiBQbHVzLCBubyBvbmUgaXMgZ29pbmcgdG8gbG9v ayBpbiByZWNvcmQtYnRyYWNlLmMgZm9yDQo+ICJzbWFydCBkaXNhc3NlbWJs eSBzdXBwb3J0Ii4NCj4gZGlzYXNtLmMgc2hvdWxkIGJlIHByb3ZpZGluZyB0 aGUgbmVjZXNzYXJ5IEFQSQ0KPiB0aGF0IHRoZSByZXN0IG9mIGdkYiBhbiB1 c2UuDQoNCk9LLCBJJ2xsIGxvb2sgaW50byBpdC4gIEkgaGF2ZSBhIGZldyBv dGhlciB0aGluZ3MgdG8gZG8gZmlyc3QuDQoNCkkgd291bGRuJ3QgZ2V0IHRv byBmYW5jeSwgdGhvdWdoLCBhbmQgc2ltcGx5IHJlcGxhY2UgdGhlIGxvdy9o aWdoDQpQQyBwYWlyIHdpdGggYSB2ZWN0b3Igb2YgUENzLiAgV2UgbWF5IGhh dmUgYSBzbWFsbCB3cmFwcGVyIHRoYXQNCmdlbmVyYXRlcyB0aGUgdmVjdG9y IG91dCBvZiBhIGxvdy9oaWdoIHBhaXIgdG8ga2VlcCB0aGUgb3JpZ2luYWwN CkFQSS4NCg0KUmVnYXJkcywNCk1hcmt1cy4NCkludGVsIERldXRzY2hsYW5k IEdtYkgKUmVnaXN0ZXJlZCBBZGRyZXNzOiBBbSBDYW1wZW9uIDEwLTEyLCA4 NTU3OSBOZXViaWJlcmcsIEdlcm1hbnkKVGVsOiArNDkgODkgOTkgODg1My0w LCB3d3cuaW50ZWwuZGUKTWFuYWdpbmcgRGlyZWN0b3JzOiBDaHJpc3RpbiBF aXNlbnNjaG1pZCwgUHJvZi4gRHIuIEhlcm1hbm4gRXVsCkNoYWlycGVyc29u IG9mIHRoZSBTdXBlcnZpc29yeSBCb2FyZDogVGlmZmFueSBEb29uIFNpbHZh ClJlZ2lzdGVyZWQgT2ZmaWNlOiBNdW5pY2gKQ29tbWVyY2lhbCBSZWdpc3Rl cjogQW10c2dlcmljaHQgTXVlbmNoZW4gSFJCIDE4NjkyOAo= >From gdb-patches-return-125301-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Aug 17 08:53:26 2015 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 101760 invoked by alias); 17 Aug 2015 08:53:26 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 101750 invoked by uid 89); 17 Aug 2015 08:53:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Mon, 17 Aug 2015 08:53:15 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id C4FD492486; Mon, 17 Aug 2015 08:53:13 +0000 (UTC) Received: from blade.nx (ovpn-116-91.ams2.redhat.com [10.36.116.91]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7H8rCFI018139; Mon, 17 Aug 2015 04:53:12 -0400 Received: by blade.nx (Postfix, from userid 1000) id 14BDA26228E; Mon, 17 Aug 2015 09:53:11 +0100 (BST) Date: Mon, 17 Aug 2015 08:53:00 -0000 From: Gary Benson To: Joel Brobecker Cc: Sandra Loosemore , Doug Evans , Jan Kratochvil , gdb-patches , Pedro Alves , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH 0/2] Better handling of slow remote transfers Message-ID: <20150817085310.GC25320@blade.nx> References: <001a11c301b0388ac5051d0c5ab8@google.com> <20150811185519.GA28644@host1.jankratochvil.net> <20150811195943.GC22245@adacore.com> <20150812094831.GD11096@blade.nx> <20150814182648.GO22245@adacore.com> <55CE6AA3.8000300@codesourcery.com> <20150816184913.GA2998@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150816184913.GA2998@adacore.com> X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00416.txt.bz2 Content-length: 3281 Joel Brobecker wrote: > Sandra Loosemore wrote: > > It actually looks to me like we are not any closer to having this > > resolved than we were at the beginning of the week. Gary's last > > patch for ^C handling didn't work for me and he said he is out of > > ideas. I am willing to try out patches, but I'm really swamped > > with other tasks right now as well as being totally unfamiliar > > with the internals of this code, so it's not reasonable to think I > > could fix this myself in time for the 7.10 release. And AFAIK > > nobody else is working on this either. :-( > > I think the situation is a little better than you describe. As far > as I understand, there is one patch that changes the default for > sysroot back to ""; it is expected to restore the current behavior > in your case, but at the same time introduces a change in behavior > in one specific situation where someone is debugging remotely > without providing the executable to GDB (either through the > command-line or using the "file" command). The change of behavior > and how to control it is what's being debated at the moment, and is > why you're still seeing the issue. Just to clarify, the default sysroot of "target:" has two purposes: 1. It allows GDB to locate and access binaries on remote targets without having to be told where they are. 2. It allows GDB to locate and access binaries on native targets when the inferior is running in a container. Resetting the default sysroot to "" disables both cases. The second is arguably more important, because without it users can attach to a local process (with, e.g., gdb -p PID) but GDB can end up loading the wrong symbols if binaries with the same paths exist both within the container and on the host machine. > Parallel to that, my understanding of the situation is that there is > a secondary issue of not being able interrupt a file transfer. That > is what you've been testing so far, I believe. Lack of success so > far is a little fustrating for everyone, I'm sure. But I am still > wondering whether you should even be in the situation where you need > to interrupt in the first place. > > That's why, to me, the first discussion has a little more weight. > We'll want to figure out the mystery in the secondary issue, but > if we can find the right approach in the first discussion for 7.10, > that would buy us some extra time in terms of being able to interrupt > file transfers. It seems to me that being able to interrupt file transfers is polish. With the warning patch alone, users will see the warning and the hint about how to restore the previous default, which they can apply and continue as before. If they have to wait out a transfer then it will presumably only be once. I know some people use GDB on systems with 5,000+ shared libraries, and others use GDB on slow serial links, but I don't think anybody combines these cases. So, would the warning+hint patch alone be enough? FWIW the reason I am out of ideas for making transfers interruptible is that both QUIT patches I supplied allow me to interrupt transfers. Something is obviously different on Sandra's setup to mine, but I don't know what, and without a reproducer I'm just stabbing in the dark. Thanks, Gary -- http://gbenson.net/