From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86822 invoked by alias); 8 Jan 2020 15:48:55 -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 86741 invoked by uid 89); 8 Jan 2020 15:48:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=gary, Gary, Commercial, December X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2020 15:48:52 +0000 Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 07:48:49 -0800 Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga007.fm.intel.com with ESMTP; 08 Jan 2020 07:48:49 -0800 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:49 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX155.amr.corp.intel.com (10.22.240.21) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:48 -0800 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.59) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n7nopfLua0qhV76U6UjGgoONTOra6qxOkqe2HBSB0Gk48fcSMTY3SNE2CxdDR/7NRs9XHFY6BrvyMfx3TuOMKejWMdqpJylQ8aDiVEl71Qb6HQUu120Nh6zHYQAvukG0VAb6kje+xyZwO2fMLN3HfNe4jrpn30S1s+NBLFCRDJmCevVP222TgYb+tN5NP/j77EUjaEwTfaegHsVG1AFEzdc7hNy47qhYxtlsf/NjWvWwq51VpJbe1Du1XuqfbVCCdW68SKouHtiITqk1KE+ynSEeN8vQg0MhUCOUl89GJ2EA1A05y5LL8LSZHkmwjfyJ5Xbq31v2VfiLCZIEsYKZxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2L5fubMijqckAq19e/RFT77EyZ7kUEWe9EoeoUGOoE=; b=Dq5t9iWx2xBPmP9AyfLyRmimCaTrusmauvLmNqFX2X9cM7d8Kk0CA28JL0gd20C1Mt4quIvZ8fbTa58qTmODZQZnxqKC17HavA8ed0PTj3pCNeqKnEHn2ThDwWIX3oiTWlmDOqwvfP/SBq9Q6cgOmfvOhJlEAbZ9nZayhcfLErXcqkfZoLCZrwKc77pgKuUofoYajtTNhLoYiUgjSmljR5Xowc9driefrW9F5Gjn9AYMpzwdK82sfMd4j4VdHaWflKuAg/SkRWRgrqQfP81JqA2Wpam7L6C/OVauj9sVrRr7gN48hxBnYY4B4Z9Qi+uQWdH6tTyIawnxwnI/HaQFBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2L5fubMijqckAq19e/RFT77EyZ7kUEWe9EoeoUGOoE=; b=uHf6HdkGwdi/EU679FNfM8kwhEB7hO5hsICe+XcOT4IYkZagSPBoBBWD7x5hxkD/XgN8hNGQ4JqurlDes5oEmFbDcIfWPRfOHqkAglRi2z6aAX3uaILg2oFHEYJg8dhRQKMmvmYCdbMn0OAW4EgFTIyORYT4cQDMISMR/sZ0Cug= Received: from BYAPR11MB3030.namprd11.prod.outlook.com (20.177.225.91) by BYAPR11MB2888.namprd11.prod.outlook.com (20.177.226.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Wed, 8 Jan 2020 15:48:47 +0000 Received: from BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b]) by BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b%6]) with mapi id 15.20.2602.017; Wed, 8 Jan 2020 15:48:47 +0000 From: "Aktemur, Tankut Baris" To: Pedro Alves CC: "gdb-patches@sourceware.org" , "Paunovic, Aleksandar" Subject: RE: [PATCH] Switch the inferior too in switch_to_program_space_and_thread (Re: [PATCH v2 08/24] Introduce switch_to_inferior_no_thread) Date: Wed, 08 Jan 2020 15:48:00 -0000 Message-ID: References: <20191017225026.30496-1-palves@redhat.com> <20191017225026.30496-9-palves@redhat.com> <489c25ee-b0ae-6a17-65cc-32c5d7c652d2@redhat.com> In-Reply-To: <489c25ee-b0ae-6a17-65cc-32c5d7c652d2@redhat.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=tankut.baris.aktemur@intel.com; x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: txZWhp90YvaRV4Qivv1Rlzwl9oYXwBxTOrQBTft2HgUgY3bkbkbCiIGqbR/a5eTJPc1H5artNFbTbCdXhybSA7zt9i4xZNB5/t4McUmr1Ko= Return-Path: tankut.baris.aktemur@intel.com Content-Transfer-Encoding: base64 X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00180.txt.bz2 T24gTW9uZGF5LCBEZWNlbWJlciAyMywgMjAxOSA4OjMwIFBNLCBQZWRybyBB bHZlcyB3cm90ZToNCj4gDQo+IE9uIDEyLzIwLzE5IDY6NTAgUE0sIFBlZHJv IEFsdmVzIHdyb3RlOg0KPiANCj4gPiBPaCB3b3csIHRoYW5rcyBtdWNoIGZv ciB0aGlzLiAgWW91J3JlIHJpZ2h0LiAgSSdtIHdvcmtpbmcgb24NCj4gPiBj b252ZXJ0aW5nIHlvdXIgZXhhbXBsZSBhYm92ZSB0byBhIHRlc3RzdWl0ZSB0 ZXN0Y2FzZS4NCj4gDQo+IEhlcmUgaXQgaXMuICBJJ20gcHV0dGluZyB0aGlz IGF0IHRoZSBlbmQgb2YgdGhlIHNlcmllcywgYWZ0ZXIgdGhlDQo+IG11bHRp LXRhcmdldCBwYXRjaGVzLCBiZWNhdXNlIGJlZm9yZSBtdWx0aS10YXJnZXQs IHRoZSB0ZXN0DQo+IGZhaWxzIC0tIEdEQiBzZW5kcyBhIHNwdXJpb3VzIEhn MC4wIHBhY2tldCB0byB0aGUgcmVtb3RlIHNpZGUuDQo+IA0KPiBGcm9tIDgz OWJiMzI5ODNkOGFmYjA4NWVlZWMxYWM2Y2E0OTlmNWJiZDYyNDQgTW9uIFNl cCAxNyAwMDowMDowMCAyMDAxDQo+IEZyb206IEFsZWtzYW5kYXIgUGF1bm92 aWMgPGFsZWtzYW5kYXIucGF1bm92aWNAaW50ZWwuY29tPg0KPiBEYXRlOiBN b24sIDIzIERlYyAyMDE5IDE4OjA0OjMyICswMDAwDQo+IFN1YmplY3Q6IFtQ QVRDSF0gU3dpdGNoIHRoZSBpbmZlcmlvciB0b28gaW4gc3dpdGNoX3RvX3By b2dyYW1fc3BhY2VfYW5kX3RocmVhZA0KPiANCj4gV2l0aCBtdWx0aS10YXJn ZXQsIGVhY2ggaW5mZXJpb3Igbm93IGhhcyBpdHMgb3duIHRhcmdldCBjb25u ZWN0aW9uLg0KPiBUaGUgcHJvYmxlbSBpbiBzd2l0Y2hfdG9fcHJvZ3JhbV9z cGFjZV9hbmRfdGhyZWFkIGlzIHRoYXQgaW4gdGhlDQo+IGN1cnJlbnQgc3Rh dGUgR0RCIHN3aXRjaGVzIHRvICJubyB0aHJlYWQiIGFuZCBhbHNvIHNldHMg dGhlIHByb2dyYW0NCj4gc3BhY2UgYnV0IGJlY2F1c2UgdGhlIGluZmVyaW9y IGlzIG5vdCBzd2l0Y2hlZCwgcG90ZW50aWFsbHkgYW4NCj4gaW5jb3JyZWN0 IHRhcmdldCByZW1haW5zIHNlbGVjdGVkLg0KPiANCj4gSGVyZSBpcyBhIHNh bXBsZSBzY2VuYXJpbyB0aGF0IGV4cGxvaXRzIHRoaXMgZmxvdzoNCj4gDQo+ IE9uIHRlcm1pbmFsIDEsIHN0YXJ0IGEgZ2Ric2VydmVyIG9uIGEgcHJvZ3Jh bSBuYW1lZCBmb286DQo+IA0KPiAgJCBnZGJzZXJ2ZXIgOjEyMzQgLi9mb28N Cj4gDQo+IE9uIHRlcm1pbmFsIDIsIHN0YXJ0IGdkYiBvbiBhIHByb2dyYW0g bmFtZWQgYmFyLiAgU3VwcG9zZSBmb28gYW5kIGJhcg0KPiBhcmUgY29tcGls ZWQgZnJvbSBmb28uYyBhbmQgYmFyLmMuICBUaGV5IGFyZSBjb21wbGV0ZWx5 IHNlcGFyYXRlLiAgU28sDQo+IGJhci5jOjIgaGFzIG5vIG1lYW5pbmcgZm9y IGZvby4NCj4gDQo+ICAkIGdkYiAtcSAuL2Jhcg0KPiAgUmVhZGluZyBzeW1i b2xzIGZyb20gLi9iYXIuLi4NCj4gIChnZGIpIGFkZC1pbmZlcmlvcg0KPiAg W05ldyBpbmZlcmlvciAyXQ0KPiAgQWRkZWQgaW5mZXJpb3IgMg0KPiAgKGdk YikgaW5mZXJpb3IgMg0KPiAgW1N3aXRjaGluZyB0byBpbmZlcmlvciAyIFs8 bnVsbD5dICg8bm9leGVjPildDQo+ICAoZ2RiKSB0YXJnZXQgcmVtb3RlIDox MjM0DQo+ICAuLi4NCj4gIChnZGIpIHNldCBkZWJ1ZyByZW1vdGUgMg0KPiAg KGdkYikgYnJlYWsgYmFyLmM6Mg0KPiAgU2VuZGluZyBwYWNrZXQ6ICRIZ3Aw LjAjYWQuLi5QYWNrZXQgcmVjZWl2ZWQ6IE9LDQo+ICBTZW5kaW5nIHBhY2tl dDogJG01ZmEsMTIjZjguLi5QYWNrZXQgcmVjZWl2ZWQ6IEUwMQ0KPiAgU2Vu ZGluZyBwYWNrZXQ6ICRtNWZhLDEjYzYuLi5QYWNrZXQgcmVjZWl2ZWQ6IEUw MQ0KPiAgU2VuZGluZyBwYWNrZXQ6ICRtNWZiLDMjYzkuLi5QYWNrZXQgcmVj ZWl2ZWQ6IEUwMQ0KPiAgU2VuZGluZyBwYWNrZXQ6ICRtNWZlLDEjY2EuLi5Q YWNrZXQgcmVjZWl2ZWQ6IEUwMQ0KPiAgQnJlYWtwb2ludCAxIGF0IDB4NWZl OiBmaWxlIGJhci5jLCBsaW5lIDIuDQo+ICAoZ2RiKQ0KPiANCj4gSGVyZSB3 ZSBoYXZlIGFuIHVubmVjZXNzYXJ5IHNlbmRpbmcgb2YgdGhlIHBhY2tldHMg dG8gdGhlIGdkYnNlcnZlci4NCj4gDQo+IFdpdGggdGhpcyBmaXggaW4gcHJv Z3NwYWNlLWFuZC10aHJlYWQuYywgd2UnbGwgZ2V0IHRoaXM6DQo+IA0KPiAg KGdkYikgYnJlYWsgYmFyLmM6Mg0KPiAgQnJlYWtwb2ludCAxIGF0IDB4NWZl OiBmaWxlIGJhci5jLCBsaW5lIDIuDQo+ICAoZ2RiKQ0KPiANCj4gTm93IHRo ZXJlIGlzIG5vIHNlbmRpbmcgb2YgdGhlIHBhY2tldHMgdG8gZ2Ric2VydmVy Lg0KPiANCj4gZ2RiL0NoYW5nZUxvZzoNCj4geXl5eS1tbS1kZCAgQWxla3Nh bmRhciBQYXVub3ZpYyAgPGFsZWtzYW5kYXIucGF1bm92aWNAaW50ZWwuY29t Pg0KPiAJICAgIFBlZHJvIEFsdmVzICA8cGFsdmVzQHJlZGhhdC5jb20+DQo+ IA0KPiAJKiBwcm9nc3BhY2UtYW5kLXRocmVhZC5jIChzd2l0Y2hfdG9fcHJv Z3JhbV9zcGFjZV9hbmRfdGhyZWFkKToNCj4gCUFzc2VydCB0aGVyZSdzIGFu IGluZmVyaW9yIGZvciBQU1BBQ0UuICBVc2UNCj4gCXN3aXRjaF90b19pbmZl cmlvcl9ub190aHJlYWQgdG8gc3dpdGNoIHRoZSBpbmZlcmlvciB0b28uDQo+ IA0KPiBnZGIvdGVzdHN1aXRlL0NoYW5nZUxvZzoNCj4geXl5eS1tbS1kZCAg UGVkcm8gQWx2ZXMgIDxwYWx2ZXNAcmVkaGF0LmNvbT4NCj4gDQo+IAkqIGdk Yi5zZXJ2ZXIvYmtwdC1vdGhlci1pbmZlcmlvci5leHA6IE5ldyBmaWxlLg0K PiAtLS0NCj4gIGdkYi9wcm9nc3BhY2UtYW5kLXRocmVhZC5jICAgICAgICAg ICAgICAgICAgICAgICB8ICA2ICstDQo+ICBnZGIvdGVzdHN1aXRlL2dkYi5z ZXJ2ZXIvYmtwdC1vdGhlci1pbmZlcmlvci5leHAgfCA5MyArKysrKysrKysr KysrKysrKysrKysrKysNCj4gIDIgZmlsZXMgY2hhbmdlZCwgOTYgaW5zZXJ0 aW9ucygrKSwgMyBkZWxldGlvbnMoLSkNCj4gIGNyZWF0ZSBtb2RlIDEwMDY0 NCBnZGIvdGVzdHN1aXRlL2dkYi5zZXJ2ZXIvYmtwdC1vdGhlci1pbmZlcmlv ci5leHANCj4gDQo+IGRpZmYgLS1naXQgYS9nZGIvcHJvZ3NwYWNlLWFuZC10 aHJlYWQuYyBiL2dkYi9wcm9nc3BhY2UtYW5kLXRocmVhZC5jDQo+IGluZGV4 IDNjOTJiNWM4ZTAuLmQ1MTc0ODAzNWUgMTAwNjQ0DQo+IC0tLSBhL2dkYi9w cm9nc3BhY2UtYW5kLXRocmVhZC5jDQo+ICsrKyBiL2dkYi9wcm9nc3BhY2Ut YW5kLXRocmVhZC5jDQo+IEBAIC0yNSw4ICsyNSw5IEBAIHZvaWQNCj4gIHN3 aXRjaF90b19wcm9ncmFtX3NwYWNlX2FuZF90aHJlYWQgKHByb2dyYW1fc3Bh Y2UgKnBzcGFjZSkNCj4gIHsNCj4gICAgaW5mZXJpb3IgKmluZiA9IGZpbmRf aW5mZXJpb3JfZm9yX3Byb2dyYW1fc3BhY2UgKHBzcGFjZSk7DQo+ICsgIGdk Yl9hc3NlcnQgKGluZiAhPSBudWxscHRyKTsNCg0KDQpUaGlzIGNyZWF0ZXMg ZmFpbHVyZSBpbiBnZGIuYmFzZS9zdGVwLW92ZXItZXhpdC5leHAuICBUaGUg cHJvYmxlbSBpcywgYSBmb3JrZWQNCmNoaWxkIHRlcm1pbmF0ZXMsIGFuZCBH REIgdHJpZXMgdG8gc3dpdGNoIHRvIHRoZSBwc3BhY2Ugb2YgdGhhdCBuby1s b25nZXItZXhpc3RpbmcNCmluZmVyaW9yIHRocm91Z2ggYSByZW1haW5pbmcg YnJlYWtwb2ludCBsb2NhdGlvbi4gIFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8g Z3VhcmQNCmNhbGxzIHRvIGBzd2l0Y2hfdG9fcHJvZ3JhbV9zcGFjZV9hbmRf dGhyZWFkYCBhcyBiZWxvdywgZm9yIGV4YW1wbGU/DQoNCmRpZmYgLS1naXQg YS9nZGIvYnJlYWtwb2ludC5jIGIvZ2RiL2JyZWFrcG9pbnQuYw0KaW5kZXgg MDgwZTg0N2RlMS4uMzBhZjYwM2M3MyAxMDA2NDQNCi0tLSBhL2dkYi9icmVh a3BvaW50LmMNCisrKyBiL2dkYi9icmVha3BvaW50LmMNCkBAIC0yODc5LDYg KzI4NzksOSBAQCB1cGRhdGVfaW5zZXJ0ZWRfYnJlYWtwb2ludF9sb2NhdGlv bnMgKHZvaWQpDQogICAgICAgaWYgKCFibC0+aW5zZXJ0ZWQgfHwgIWJsLT5u ZWVkc191cGRhdGUpDQogICAgICAgIGNvbnRpbnVlOw0KDQorICAgICAgaWYg KGZpbmRfaW5mZXJpb3JfZm9yX3Byb2dyYW1fc3BhY2UgKGJsLT5wc3BhY2Up ID09IG51bGxwdHIpDQorICAgICAgIGNvbnRpbnVlOw0KKw0KICAgICAgIHN3 aXRjaF90b19wcm9ncmFtX3NwYWNlX2FuZF90aHJlYWQgKGJsLT5wc3BhY2Up Ow0KDQogICAgICAgLyogRm9yIHRhcmdldHMgdGhhdCBzdXBwb3J0IGdsb2Jh bCBicmVha3BvaW50cywgdGhlcmUncyBubyBuZWVkDQoNClRoZXJlIGFyZSBh IGhhbmRmdWwgb3RoZXIgY2FzZXMgdGhhdCBjYW4gYmUgZ3VhcmRlZC9za2lw cGVkIHNpbWlsYXJseS4NCkknbSBub3Qgc3VyZSwgdGhvdWdoLCBpZiB0aGUg cHJvYmxlbSBpcyBkZWVwZXIgYW5kIHRoZSBjYWxscyB0bw0KYHN3aXRjaF90 b19wcm9ncmFtX3NwYWNlX2FuZF90aHJlYWRgIGZvciBhIG5vbi1leGlzdGlu ZyBpbmZlcmlvciBzaG91bGQgaGF2ZQ0KbmV2ZXIgb2NjdXJyZWQuICBUaGF0 IGlzLCBzaG91bGQgdGhlIGJyZWFrcG9pbnQgbG9jYXRpb25zIG9mIGV4aXRl ZCBpbmZlcmlvcnMNCmJlIGNsZWFuZWQgdXAgbXVjaCBlYXJsaWVyLCBiZWZv cmUgd2UgY29tZSB0byB0aGlzIHBvaW50Pw0KDQotQmFyaXMNCg0KPiAtICBp ZiAoaW5mICE9IE5VTEwgJiYgaW5mLT5waWQgIT0gMCkNCj4gKyAgaWYgKGlu Zi0+cGlkICE9IDApDQo+ICAgICAgew0KPiAgICAgICAgdGhyZWFkX2luZm8g KnRwID0gYW55X2xpdmVfdGhyZWFkX29mX2luZmVyaW9yIChpbmYpOw0KPiAN Cj4gQEAgLTM5LDYgKzQwLDUgQEAgc3dpdGNoX3RvX3Byb2dyYW1fc3BhY2Vf YW5kX3RocmVhZCAocHJvZ3JhbV9zcGFjZSAqcHNwYWNlKQ0KPiAgCX0NCj4g ICAgICB9DQo+IA0KPiAtICBzd2l0Y2hfdG9fbm9fdGhyZWFkICgpOw0KPiAt ICBzZXRfY3VycmVudF9wcm9ncmFtX3NwYWNlIChwc3BhY2UpOw0KPiArICBz d2l0Y2hfdG9faW5mZXJpb3Jfbm9fdGhyZWFkIChpbmYpOw0KPiAgfQ0KSW50 ZWwgRGV1dHNjaGxhbmQgR21iSApSZWdpc3RlcmVkIEFkZHJlc3M6IEFtIENh bXBlb24gMTAtMTIsIDg1NTc5IE5ldWJpYmVyZywgR2VybWFueQpUZWw6ICs0 OSA4OSA5OSA4ODUzLTAsIHd3dy5pbnRlbC5kZQpNYW5hZ2luZyBEaXJlY3Rv cnM6IENocmlzdGluIEVpc2Vuc2NobWlkLCBHYXJ5IEtlcnNoYXcKQ2hhaXJw ZXJzb24gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBOaWNvbGUgTGF1ClJl Z2lzdGVyZWQgT2ZmaWNlOiBNdW5pY2gKQ29tbWVyY2lhbCBSZWdpc3Rlcjog QW10c2dlcmljaHQgTXVlbmNoZW4gSFJCIDE4NjkyOAo= >From gdb-patches-return-162867-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 08 15:51:28 2020 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 112281 invoked by alias); 8 Jan 2020 15:51:28 -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 112272 invoked by uid 89); 8 Jan 2020 15:51:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=Ali, H*r:authenticated X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2020 15:51:25 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 008FpHdn023792 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jan 2020 10:51:22 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 008FpHdn023792 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1578498683; bh=UMwliXR4gTk4zcLs0lMWGBpgcRA7sbwMgzpGkiHw7Oo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oY/xtdjHLajUvwfjrFbxC5gXASdY+8bUoP1Lxx5JtRHuEtRGrrVcHqmhi6rRg3Hrt HBHup/EcgcHX17xRKThUME1BZkZdQQQ4bXdp2G3j554T4w9AKtYT8Vrpi3ZAYrORdv kDBoxW/78zJcjGD+Z29DN7RI0QmWyJK+PrgrS7kk= Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B97E01E059; Wed, 8 Jan 2020 10:51:16 -0500 (EST) Subject: Re: [PATCH] Dwarf 5: Handle debug_str_offsets and indexed attributes that have base offsets. To: Ali Tamur , gdb-patches@sourceware.org References: <9e86baf4-ffbc-916a-6f29-c2027f39898e@polymtl.ca> <20200108051920.176688-1-tamur@google.com> From: Simon Marchi Message-ID: Date: Wed, 08 Jan 2020 15:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200108051920.176688-1-tamur@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00181.txt.bz2 Content-length: 11278 On 2020-01-08 12:19 a.m., Ali Tamur wrote: > Hi, > Thank you for the review, all your suggestions are spot on and the patch is > much more cleaner now. > >> Can you explain why we need to use the "follow" version here (passing true as the third > argument)? > It turned out to be unnecessary, removed. > >> If you do get rid of str_is_string_index, I think this change won't be necessary anymore, > since it will essentially just end up using DW_STRING. > Yes, I deleted str_is_string_index. > >> From what I understand, cu->str_offsets_base will have already been set by > read_full_die so it would be unnecessary to do so here. > Removed. > >> Could the changes in this function be simpler, do we really need to do > two passes on the attributes? > Done. > >> You could use the std::vector constructor that creates the vector with > the right size from the start > Done. > >> Since we now iterate on the vector, this loop can be >> >> for (const attribute &attr : attr_vec) > Done. > >> I'd suggest adding a default case with: >> >> gdb_assert_not_reached (_("Unexpected DWARF form."); > Done. > >> It appears that with this patch, str_is_string_index is never set to true. > Removed. Hi Ali, Thanks, here are a few more comments. I'm probably being a little bit picky, but I really want to avoid adding any unnecessary complexity in this code that is already very complex. > @@ -500,27 +501,25 @@ public: > There is an invariant here that is important to remember: > Except for attributes copied from the top level DIE in the "main" > (or "stub") file in preparation for reading the DWO file > - (e.g., DW_AT_GNU_addr_base), we KISS: there is only *one* CU. > + (e.g., DW_AT_addr_base), we KISS: there is only *one* CU. > Either there isn't a DWO file (in which case this is NULL and the point > is moot), or there is and either we're not going to read it (in which > case this is NULL) or there is and we are reading it (in which case this > is non-NULL). */ > struct dwo_unit *dwo_unit = nullptr; > > - /* The DW_AT_addr_base attribute if present, zero otherwise > - (zero is a valid value though). > + /* The DW_AT_addr_base (DW_AT_GNU_addr_base) attribute if present. > Note this value comes from the Fission stub CU/TU's DIE. */ > - ULONGEST addr_base = 0; > + gdb::optional addr_base {}; You don't need the {}, as the optional will be default-constructed empty in any case. > > - /* The DW_AT_ranges_base attribute if present, zero otherwise > - (zero is a valid value though). > + /* The DW_AT_rnglists_base attribute if present. > Note this value comes from the Fission stub CU/TU's DIE. > Also note that the value is zero in the non-DWO case so this value can > be used without needing to know whether DWO files are in use or not. > N.B. This does not apply to DW_AT_ranges appearing in > DW_TAG_compile_unit dies. This is a bit of a wart, consider if ever > DW_AT_ranges appeared in the DW_TAG_compile_unit of DWO DIEs: then > - DW_AT_ranges_base *would* have to be applied, and we'd have to care > + DW_AT_rnglists_base *would* have to be applied, and we'd have to care > whether the DW_AT_ranges attribute came from the skeleton or DWO. */ > ULONGEST ranges_base = 0; > > @@ -532,6 +531,12 @@ public: > all such types here and process them after expansion. */ > std::vector rust_unions; > > + /* The DW_AT_str_offsets_base attribute if present. For DWARF 4 version DWO > + files, the value is implicitly zero. For DWARF 5 version DWO files, the > + value is often implicit and is the size of the header of > + .debug_str_offsets section (8 or 4, depending on the address size). */ > + gdb::optional str_offsets_base {}; Same here. > @@ -7182,7 +7203,35 @@ lookup_signatured_type (struct dwarf2_cu *cu, ULONGEST sig) > return entry; > } > } > - > + > +/* Return the address base of the compile unit, which, if exists, is stored > + either at the attribute DW_AT_GNU_addr_base, or DW_AT_addr_base. */ > +static gdb::optional > +lookup_addr_base (struct dwarf2_cu *cu, struct die_info *comp_unit_die) The "cu" parameter is no longer needed. > +{ > + struct attribute *attr; > + attr = dwarf2_attr_no_follow (comp_unit_die, DW_AT_addr_base); > + if (attr == nullptr) > + attr = dwarf2_attr_no_follow (comp_unit_die, DW_AT_GNU_addr_base); > + if (attr == nullptr) > + return gdb::optional (); > + return DW_UNSND (attr); > +} > + > +/* Return range lists base of the compile unit, which, if exists, is stored > + either at the attribute DW_AT_rnglists_base or DW_AT_GNU_ranges_base. */ > +ULONGEST > +lookup_ranges_base (struct dwarf2_cu *cu, struct die_info *comp_unit_die) > +{ > + struct attribute *attr; > + attr = dwarf2_attr (comp_unit_die, DW_AT_rnglists_base, cu); > + if (attr == nullptr) > + attr = dwarf2_attr (comp_unit_die, DW_AT_GNU_ranges_base, cu); > + if (attr == nullptr) > + return 0; > + return DW_UNSND (attr); > +} I think lookup_ranges_base could use dwarf2_attr_no_follow too, and thus you could get rid of the "cu" parameter. The reasonning is that we know comp_unit_die is either a DW_TAG_compile_unit or a DW_TAG_partial_unit (I wouldn't mind if you added a gdb_assert to check that in these functions), and those DIEs can't have DW_AT_specification or DW_AT_abstract_origin, which is what dwarf2_attr checks for. > + > /* Low level DIE reading support. */ > > /* Initialize a die_reader_specs struct from a dwarf2_cu struct. */ > @@ -7243,7 +7292,6 @@ read_cutu_die_from_dwo (struct dwarf2_per_cu_data *this_cu, > struct attribute *comp_dir, *stmt_list, *low_pc, *high_pc, *ranges; > int i,num_extra_attrs; > struct dwarf2_section_info *dwo_abbrev_section; > - struct attribute *attr; > struct die_info *comp_unit_die; > > /* At most one of these may be provided. */ > @@ -7274,20 +7322,14 @@ read_cutu_die_from_dwo (struct dwarf2_per_cu_data *this_cu, > ranges = dwarf2_attr (stub_comp_unit_die, DW_AT_ranges, cu); > comp_dir = dwarf2_attr (stub_comp_unit_die, DW_AT_comp_dir, cu); > > - /* There should be a DW_AT_addr_base attribute here (if needed). > - We need the value before we can process DW_FORM_GNU_addr_index > - or DW_FORM_addrx. */ > - cu->addr_base = 0; > - attr = dwarf2_attr (stub_comp_unit_die, DW_AT_GNU_addr_base, cu); > - if (attr != nullptr) > - cu->addr_base = DW_UNSND (attr); > + auto maybe_addr_base = lookup_addr_base (cu, stub_comp_unit_die); > + if (maybe_addr_base.has_value ()) > + cu->addr_base = *maybe_addr_base; If I'm not mistaken, this could just be cu->addr_base = lookup_addr_base (cu, stub_comp_unit_die); right? If lookup_addr_base returns an empty optional, then cu->addr_base will remain an empty optional, which is what we want. > > - /* There should be a DW_AT_ranges_base attribute here (if needed). > - We need the value before we can process DW_AT_ranges. */ > - cu->ranges_base = 0; > - attr = dwarf2_attr (stub_comp_unit_die, DW_AT_GNU_ranges_base, cu); > - if (attr != nullptr) > - cu->ranges_base = DW_UNSND (attr); > + /* There should be a DW_AT_rnglists_base (DW_AT_GNU_ranges_base) attribute > + here (if needed). We need the value before we can process > + DW_AT_ranges. */ > + cu->ranges_base = lookup_ranges_base (cu, stub_comp_unit_die); > } > else if (stub_comp_dir != NULL) > { > @@ -7396,8 +7438,7 @@ read_cutu_die_from_dwo (struct dwarf2_per_cu_data *this_cu, > TUs by skipping the stub and going directly to the entry in the DWO file. > However, skipping the stub means we won't get DW_AT_comp_dir, so we have > to get it via circuitous means. Blech. */ > - if (comp_dir != NULL) > - result_reader->comp_dir = DW_STRING (comp_dir); > + result_reader->comp_dir = get_comp_dir_attr (comp_unit_die, cu); Can you explain why this change is necessary (or at least desirable)? I think it doesn't change anything, because `comp_dir` will have been assigned to `comp_unit_die`, so in the end we should read the same thing. get_comp_dir_attr now is pretty much equivalent to dwarf2_string_attr. dwarf2_string_attr does some validation on the attribute form, which could be desirable, so we could use that instead of DW_STRING directly, but I don't think using get_comp_dir_attr is useful. > @@ -17840,7 +17893,7 @@ read_base_type (struct die_info *die, struct dwarf2_cu *cu) > enum bfd_endian byte_order = gdbarch_byte_order (arch); > > attr = dwarf2_attr (die, DW_AT_endianity, cu); > - if (attr) > + if (attr != nullptr) That change is not wrong, but it's unrelated to this patch. I don't mind doing these improvements when touching the code around, but that's not the case here. However, feel free to push it separately, as an obvious patch. > @@ -18996,12 +19065,19 @@ partial_die_info::read (const struct die_reader_specs *reader, > int has_high_pc_attr = 0; > int high_pc_relative = 0; > > + std::vector attr_vec (abbrev.num_attrs); > + std::vector indexes_that_need_reprocess; > for (i = 0; i < abbrev.num_attrs; ++i) > { > - struct attribute attr; > - > - info_ptr = read_attribute (reader, &attr, &abbrev.attrs[i], info_ptr); > + bool need_reprocess; > + info_ptr = read_attribute (reader, &attr_vec[i], &abbrev.attrs[i], > + info_ptr, &need_reprocess); > + if (need_reprocess) > + read_attribute_reprocess (reader, &attr_vec[i]); > + } I think this would deserve a comment. Readers could be surprised that we reprocess attributes directly. In essence, the comment should say that we never deal with a CU DIE here, only its descendants, so the string/address offsets necessary to do the reprocessing will have already been read from the CU DIE earlier, and therefore it's safe to reprocess immediatly. > @@ -20160,27 +20264,30 @@ read_signed_leb128 (bfd *abfd, const gdb_byte *buf, > } > > /* Given index ADDR_INDEX in .debug_addr, fetch the value. > - ADDR_BASE is the DW_AT_GNU_addr_base attribute or zero. > + ADDR_BASE is the DW_AT_addr_base (DW_AT_GNU_addr_base) attribute or zero. > ADDR_SIZE is the size of addresses from the CU header. */ > > static CORE_ADDR > read_addr_index_1 (struct dwarf2_per_objfile *dwarf2_per_objfile, > - unsigned int addr_index, ULONGEST addr_base, int addr_size) > + unsigned int addr_index, gdb::optional addr_base, > + int addr_size) > { > struct objfile *objfile = dwarf2_per_objfile->objfile; > bfd *abfd = objfile->obfd; > const gdb_byte *info_ptr; > + ULONGEST addr_base_or_zero = addr_base.has_value() ? *addr_base : 0; Space before parenthesis. > +static const char * > +get_comp_dir_attr (struct die_info *die, struct dwarf2_cu *cu) > +{ > + const struct attribute *attr = dwarf2_attr (die, DW_AT_comp_dir, cu); > + if (attr == NULL) > + return NULL; > + return DW_STRING (attr); > +} As mentioned earlier, I think this can be removed, as it's doing essentially the same thing as dwarf2_string_attr. Thanks, Simon