From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16044 invoked by alias); 4 Jun 2018 15:49:41 -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 13885 invoked by uid 89); 4 Jun 2018 15:49:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=feels, ptrace X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-db5eur01on0051.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (104.47.2.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jun 2018 15:49:36 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.226.148) by DB6PR0802MB2344.eurprd08.prod.outlook.com (10.172.228.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.15; Mon, 4 Jun 2018 15:49:33 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::d984:bdee:1856:c64]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::d984:bdee:1856:c64%7]) with mapi id 15.20.0820.010; Mon, 4 Jun 2018 15:49:33 +0000 From: Alan Hayward To: Simon Marchi CC: "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 8/8] Ptrace support for Aarch64 SVE Date: Mon, 04 Jun 2018 15:49:00 -0000 Message-ID: <626E6E07-4A7B-4E1D-A86B-6C4C74EF96E1@arm.com> References: <20180511105256.27388-1-alan.hayward@arm.com> <20180511105256.27388-9-alan.hayward@arm.com> <752617dd-3221-7aa7-d626-b841fe13761c@ericsson.com> <22AC70D2-D24D-4DE9-939F-067BE65F02F3@arm.com> <0ff06fe2-396d-a9da-d95b-130f6bef2d2c@ericsson.com> In-Reply-To: <0ff06fe2-396d-a9da-d95b-130f6bef2d2c@ericsson.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; x-ms-publictraffictype: Email x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DB6PR0802MB2344: nodisclaimer: True x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016);SRVR:DB6PR0802MB2344;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0802MB2344; x-forefront-prvs: 069373DFB6 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(39860400002)(39380400002)(396003)(346002)(376002)(199004)(189003)(54906003)(316002)(6306002)(14454004)(81166006)(97736004)(966005)(33656002)(81156014)(6512007)(82746002)(72206003)(8676002)(2900100001)(57306001)(53936002)(8936002)(83716003)(3846002)(6116002)(5250100002)(7736002)(99286004)(478600001)(50226002)(66066001)(76176011)(93886005)(6506007)(6246003)(105586002)(106356001)(305945005)(6486002)(229853002)(6436002)(102836004)(26005)(2906002)(86362001)(186003)(6916009)(3660700001)(486006)(4326008)(5660300001)(68736007)(3280700002)(25786009)(476003)(446003)(11346002)(2616005)(36756003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0802MB2344;H:DB6PR0802MB2133.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8000b71b-623f-49b0-0515-08d5ca32c49d X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8000b71b-623f-49b0-0515-08d5ca32c49d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2018 15:49:33.7472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2344 X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00069.txt.bz2 DQo+Pj4+IGRpZmYgLS1naXQgYS9nZGIvbmF0L2FhcmNoNjQtc3ZlLWxpbnV4 LXB0cmFjZS5jIGIvZ2RiL25hdC9hYXJjaDY0LXN2ZS1saW51eC1wdHJhY2Uu Yw0KPj4+PiBpbmRleCA5MzgxNzg2ZmRhLi44NGM3YTQxZjQwIDEwMDY0NA0K Pj4+PiAtLS0gYS9nZGIvbmF0L2FhcmNoNjQtc3ZlLWxpbnV4LXB0cmFjZS5j DQo+Pj4+ICsrKyBiL2dkYi9uYXQvYWFyY2g2NC1zdmUtbGludXgtcHRyYWNl LmMNCj4+Pj4gQEAgLTI1LDYgKzI1LDEzIEBADQo+Pj4+ICNpbmNsdWRlICJh YXJjaDY0LXN2ZS1saW51eC1wdHJhY2UuaCINCj4+Pj4gI2luY2x1ZGUgImFy Y2gvYWFyY2g2NC5oIg0KPj4+PiANCj4+Pj4gKyNpZm5kZWYgR0RCU0VSVkVS DQo+Pj4+ICsjaW5jbHVkZSAiZGVmcy5oIg0KPj4+PiArI2VuZGlmDQo+Pj4+ ICsjaW5jbHVkZSAicmVnY2FjaGUuaCINCj4+PiANCj4+PiBIbW0gd2UgdHJ5 IG5vdCBhZGQgYW55IG1vcmUgIiNpZmRlZiBHREJTRVJWRVIiIGluIHRoZSBj b21tb24gY29kZS4NCj4+PiANCj4+PiBodHRwczovL3NvdXJjZXdhcmUub3Jn L2dkYi93aWtpL0NvbW1vbiNIZWFkZXJfZmlsZXNfaW5fY29tbW9uX2NvZGVf LjI4ZGVmcy5oX3ZzX3NlcnZlci5oLjJDX2V0Yy4uMjkNCj4+PiANCj4+PiBJ bnN0ZWFkLCB3ZSBzaG91bGQgdHJ5IGRlZmluaW5nIGEgY29tbW9uIGludGVy ZmFjZSAocHJvYmFibHkgaW4gY29tbW9uL2NvbW1vbi1yZWdjYWNoZS5oPykg dGhhdCB0aGUNCj4+PiBjb21tb24gY29kZSB3aWxsIHVzZSwgYW5kIHRoYXQg cmVnY2FjaGVzIGZyb20gR0RCIGFuZCBHREJzZXJ2ZXIgd2lsbCBpbXBsZW1l bnQuDQo+PiANCj4+IEkgdHJpZWQgdXNpbmcgY29tbW9uLWRlZnMuaCwgYnV0 IGdkYi9yZWdjYWNoZS5oIHJlcXVpcmVzIGRlZmluZXMgZnJvbQ0KPj4gZGVm cy5oIC0gUmVxdWlyZUxvbmdlc3QgYW5kIG1heWJlIG90aGVycy4NCj4+IFB1 dHRpbmcgZGVmcy5oIGF0IHRoZSB0b3Agb2YgZ2RiL3JlZ2NhY2hlLmggdGhl biBicm9rZSBpbiBhIHdlaXJkIHdheS4NCj4+IEEgbG90IG9mIGZpZGRsaW5n IGxhdGVyLCBhbmQgSSBoYWRu4oCZdCBmb3VuZCBhIHdheSB0byBtYWtlIGl0 IHdvcmsuDQo+PiANCj4+IENyZWF0aW5nIGNvbW1vbi9jb21tb24tcmVnY2Fj aGUuaCBnZXRzIGEgYml0IG9kZCBiZWNhdXNlLCB0aGUgZnVuY3Rpb25zDQo+ PiBJIG5lZWQgZm9yIGdkYnNlcnZlciAocmF3X3N1cHBseSwgcmF3X2NvbGxl Y3QgYW5kIGdldF9yZWdpc3Rlcl9zdGF0dXMpDQo+PiBvbiBnZGIgY29tZSBm cm9tOg0KPj4gDQo+PiANCj4+IGNsYXNzIHJlZ19idWZmZXINCj4+IC4uLg0K Pj4gIGVudW0gcmVnaXN0ZXJfc3RhdHVzIGdldF9yZWdpc3Rlcl9zdGF0dXMg KGludCByZWdudW0pIGNvbnN0Ow0KPj4gLi4uDQo+PiANCj4+IA0KPj4gY2xh c3MgcmVhZGFibGVfcmVnY2FjaGUgOiBwdWJsaWMgcmVnX2J1ZmZlcg0KPj4g Li4uDQo+PiANCj4+IA0KPj4gY2xhc3MgZGV0YWNoZWRfcmVnY2FjaGUgOiBw dWJsaWMgcmVhZGFibGVfcmVnY2FjaGUNCj4+IC4uLg0KPj4gIHZvaWQgcmF3 X3N1cHBseSAoaW50IHJlZ251bSwgY29uc3Qgdm9pZCAqYnVmKTsNCj4+IC4u Lg0KPj4gDQo+PiANCj4+IGNsYXNzIHJlZ2NhY2hlIDogcHVibGljIGRldGFj aGVkX3JlZ2NhY2hlDQo+PiAuLi4NCj4+ICB2b2lkIHJhd19jb2xsZWN0IChp bnQgcmVnbnVtLCB2b2lkICpidWYpIGNvbnN0Ow0KPj4gLi4uDQo+PiANCj4+ IA0KPj4gSSBkb27igJl0IHRoaW5rIHRoYXQgdGhpcyB3b3VsZCB3b3JrOg0K Pj4gY2xhc3MgcmVnY2FjaGUgOiBwdWJsaWMgZGV0YWNoZWRfcmVnY2FjaGUs IGNvbW1vbl9yZWdjYWNoZQ0KPiANCj4gSSBkaWQgc29tZSBxdWljayBoYWNr aW5nIGFuZCBpdCBzZWVtcyB0byB3b3JrIHRvIGhhdmUgdGhpcyBpbiBjb21t b24vY29tbW9uLXJlZ2NhY2hlLmgNCj4gDQo+IHN0cnVjdCByZWdfYnVmZmVy X2NvbW1vbg0KPiB7DQo+ICB2aXJ0dWFsIH5yZWdfYnVmZmVyX2NvbW1vbiAo KSA9IGRlZmF1bHQ7DQo+ICB2aXJ0dWFsIHZvaWQgcmF3X3N1cHBseSAoaW50 IHJlZ251bSwgY29uc3Qgdm9pZCAqYnVmKSA9IDA7DQo+ICB2aXJ0dWFsIHZv aWQgcmF3X2NvbGxlY3QgKGludCByZWdudW0sIHZvaWQgKmJ1ZikgY29uc3Qg PSAwOw0KPiAgdmlydHVhbCBib29sIHJhd19jb21wYXJlIChpbnQgcmVnbnVt LCBjb25zdCB2b2lkICpidWYsIGludCBvZmZzZXQpIGNvbnN0ID0gMDsNCj4g IHZpcnR1YWwgcmVnaXN0ZXJfc3RhdHVzIGdldF9yZWdpc3Rlcl9zdGF0dXMg KGludCByZWdudW0pIGNvbnN0ID0gMDsNCj4gfTsNCj4gDQo+IGFuZCBtYWtl IHlvdXIgY29kZSBpbiBuYXQvIHRha2UgYSBwb2ludGVyIHRvIHJlZ19idWZm ZXJfY29tbW9uLiAgZ2RiJ3MgcmVnX2J1ZmZlcg0KPiBhbmQgZ2Ric2VydmVy J3MgcmVnY2FjaGUgc2hvdWxkIGluaGVyaXQgZnJvbSByZWdfYnVmZmVyX2Nv bW1vbi4gIEkgIGJ1aWx0DQo+IGl0IG9uIG90aGVyIHJlZ2NhY2hlIHJlZmFj dG9yIHBhdGNoZXMgSSBoYXZlIGluIHRoZSBwaXBlbGluZSwgc28gbWF5YmUg c29tZSBvdGhlcg0KPiBjaGFuZ2VzIGluIHRoZXJlIGFyZSBuZWVkZWQsIG1h eWJlIG5vdC4gIEkgcHVzaGVkIHRoZSByZXN1bHQgb24gdGhpcyBicmFuY2gs IGl0J3MNCj4gYSBiaXQgcmF3IGJ1dCBpdCBzaG91bGQgYmUgZW5vdWdoIHRv IHNob3cgdGhlIGlkZWEuDQo+IA0KPiBodHRwczovL3NvdXJjZXdhcmUub3Jn L2dpdC9naXR3ZWIuY2dpP3A9YmludXRpbHMtZ2RiLmdpdDthPXNob3J0bG9n O2g9cmVmcy9oZWFkcy91c2Vycy9zaW1hcmsvcmVnY2FjaGUtZm9yLWFsYW4N Cg0KVGhhbmtzIGZvciB0cnlpbmcgdGhpcyBvdXQsIGhvd2V2ZXIgSSB0cmll ZCBhZGRpbmcgeW91ciBjaGFuZ2VzDQppbnRvIG15IGJ1aWxkLCBidXQgdGhh dCByZXN1bHRzIGluIHRoZSBmb2xsb3dpbmc6DQoNCi4uLy4uL3NyYy9iaW51 dGlscy1nZGIvZ2RiL2xpbnV4LWZvcmsuYzogSW4gZnVuY3Rpb24g4oCYdm9p ZCBmb3JrX3NhdmVfaW5mcnVuX3N0YXRlKGZvcmtfaW5mbyosIGludCnigJk6 DQouLi8uLi9zcmMvYmludXRpbHMtZ2RiL2dkYi9saW51eC1mb3JrLmM6Mjk4 Ojc1OiBlcnJvcjogaW52YWxpZCBuZXctZXhwcmVzc2lvbiBvZiBhYnN0cmFj dCBjbGFzcyB0eXBlIOKAmHJlYWRvbmx5X2RldGFjaGVkX3JlZ2NhY2hl4oCZ DQogICBmcC0+c2F2ZWRyZWdzID0gbmV3IHJlYWRvbmx5X2RldGFjaGVkX3Jl Z2NhY2hlICgqZ2V0X2N1cnJlbnRfcmVnY2FjaGUgKCkpOw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXg0KSW4gZmlsZSBpbmNsdWRlZCBmcm9t IC4uLy4uL3NyYy9iaW51dGlscy1nZGIvZ2RiL2dkYmFyY2guaDo3MDowLA0K ICAgICAgICAgICAgICAgICBmcm9tIC4uLy4uL3NyYy9iaW51dGlscy1nZGIv Z2RiL2RlZnMuaDo1MzEsDQogICAgICAgICAgICAgICAgIGZyb20gLi4vLi4v c3JjL2JpbnV0aWxzLWdkYi9nZGIvbGludXgtZm9yay5jOjIwOg0KLi4vLi4v c3JjL2JpbnV0aWxzLWdkYi9nZGIvcmVnY2FjaGUuaDozNjc6Nzogbm90ZTog ICBiZWNhdXNlIHRoZSBmb2xsb3dpbmcgdmlydHVhbCBmdW5jdGlvbnMgYXJl IHB1cmUgd2l0aGluIOKAmHJlYWRvbmx5X2RldGFjaGVkX3JlZ2NhY2hl4oCZ Og0KIGNsYXNzIHJlYWRvbmx5X2RldGFjaGVkX3JlZ2NhY2hlIDogcHVibGlj IHJlYWRhYmxlX3JlZ2NhY2hlDQogICAgICAgXg0KSW4gZmlsZSBpbmNsdWRl ZCBmcm9tIC4uLy4uL3NyYy9iaW51dGlscy1nZGIvZ2RiL3JlZ2NhY2hlLmg6 MjM6MCwNCiAgICAgICAgICAgICAgICAgZnJvbSAuLi8uLi9zcmMvYmludXRp bHMtZ2RiL2dkYi9nZGJhcmNoLmg6NzAsDQogICAgICAgICAgICAgICAgIGZy b20gLi4vLi4vc3JjL2JpbnV0aWxzLWdkYi9nZGIvZGVmcy5oOjUzMSwNCiAg ICAgICAgICAgICAgICAgZnJvbSAuLi8uLi9zcmMvYmludXRpbHMtZ2RiL2dk Yi9saW51eC1mb3JrLmM6MjA6DQouLi8uLi9zcmMvYmludXRpbHMtZ2RiL2dk Yi9jb21tb24vY29tbW9uLXJlZ2NhY2hlLmg6Njg6MTY6IG5vdGU6IAl2aXJ0 dWFsIHZvaWQgcmVnX2J1ZmZlcl9jb21tb246OnJhd19zdXBwbHkoaW50LCBj b25zdCB2b2lkKikNCiAgIHZpcnR1YWwgdm9pZCByYXdfc3VwcGx5IChpbnQg cmVnbnVtLCBjb25zdCB2b2lkICpidWYpID0gMDsNCiAgICAgICAgICAgICAg ICBeDQouLi8uLi9zcmMvYmludXRpbHMtZ2RiL2dkYi9jb21tb24vY29tbW9u LXJlZ2NhY2hlLmg6Njk6MTY6IG5vdGU6IAl2aXJ0dWFsIHZvaWQgcmVnX2J1 ZmZlcl9jb21tb246OnJhd19jb2xsZWN0KGludCwgdm9pZCopIGNvbnN0DQog ICB2aXJ0dWFsIHZvaWQgcmF3X2NvbGxlY3QgKGludCByZWdudW0sIHZvaWQg KmJ1ZikgY29uc3QgPSAwOw0KDQoNCkFuZCB0aGVuIHNpbWlsYXIgZXJyb3Jz IHRyeWluZyB0byBjcmVhdGUgYSByZWdpc3Rlcl9kdW1wX3JlZ19idWZmZXIu DQoNCg0KSSBjb3VsZCB0aGVuIGFkZCB0aGUgZm9sbG93aW5nIHRvIHJlYWRv bmx5X2RldGFjaGVkX3JlZ2NhY2hlOg0KDQogIHZvaWQgcmF3X3N1cHBseSAo aW50IHJlZ251bSwgY29uc3Qgdm9pZCAqYnVmKSBvdmVycmlkZQ0KICB7IGdk Yl9hc3NlcnQoZmFsc2UpOyB9DQoNCiAgdm9pZCByYXdfY29sbGVjdCAoaW50 IHJlZ251bSwgdm9pZCAqYnVmKSBjb25zdCBvdmVycmlkZQ0KICB7IGdkYl9h c3NlcnQoZmFsc2UpOyB9DQoNCi4uLk9yIGV2ZW4gbWFrZSB0aGUgbWV0aG9k cyBpbiByZWdfYnVmZmVyX2NvbW1vbiBoYXZlIGENCnsgZ2RiX2Fzc2VydChm YWxzZSk7IH0gYm9keS4NCg0KQnV0IHRoYXQgZmVlbHMgd3JvbmcsIGFzIGl0 4oCZcyBicmVha2luZyB0aGUgbmljZSByZWdjYWNoZSBhYnN0cmFjdGlvbnMu DQoNCkFueSB0aG91Z2h0cz8NCg0KQWxhbi4= >From gdb-patches-return-147927-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Jun 04 16:31:10 2018 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 56062 invoked by alias); 4 Jun 2018 16:30:59 -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 55981 invoked by uid 89); 4 Jun 2018 16:30:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr50050.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.107.5.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jun 2018 16:30:47 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.226.148) by DB6PR0802MB2375.eurprd08.prod.outlook.com (10.172.228.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Mon, 4 Jun 2018 16:30:42 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::d984:bdee:1856:c64]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::d984:bdee:1856:c64%7]) with mapi id 15.20.0820.010; Mon, 4 Jun 2018 16:30:41 +0000 From: Alan Hayward To: Pedro Alves CC: "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH] Use ELF_SECTION_IN_SEGMENT to map segments Date: Mon, 04 Jun 2018 16:30:00 -0000 Message-ID: <52A10F53-A53B-40FC-8CB4-2BD38CFBF67E@arm.com> References: <20180522110019.3839-1-alan.hayward@arm.com> <03e86682-9850-ea5d-1e4e-2bb897a55a7f@redhat.com> <7AE0B529-EB5F-4876-8097-F0798EF00DE9@arm.com> In-Reply-To: <7AE0B529-EB5F-4876-8097-F0798EF00DE9@arm.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; x-ms-publictraffictype: Email x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DB6PR0802MB2375: nodisclaimer: True x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016);SRVR:DB6PR0802MB2375;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0802MB2375; x-forefront-prvs: 069373DFB6 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(346002)(39860400002)(396003)(376002)(39380400002)(189003)(51914003)(199004)(25786009)(486006)(106356001)(66066001)(6486002)(57306001)(53546011)(97736004)(26005)(102836004)(186003)(6506007)(50226002)(14454004)(105586002)(7736002)(99286004)(5660300001)(68736007)(2906002)(305945005)(6436002)(229853002)(5250100002)(76176011)(2900100001)(54906003)(11346002)(3660700001)(316002)(83716003)(4326008)(2616005)(476003)(72206003)(6116002)(3846002)(8936002)(6916009)(81166006)(81156014)(6512007)(8676002)(86362001)(53936002)(82746002)(36756003)(446003)(478600001)(33656002)(6246003)(3280700002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0802MB2375;H:DB6PR0802MB2133.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <366D3E94AC097043B537845B7287BFBB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bb2304fb-b97b-47af-a822-08d5ca3883b8 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb2304fb-b97b-47af-a822-08d5ca3883b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2018 16:30:41.8428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2375 X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00070.txt.bz2 Content-length: 3172 UHVzaGVkIHRoaXMgd2l0aCBjaGFuZ2VzIGFzIHN1Z2dlc3RlZC4NCg0KVGhl IEJGRCBwYXRjaCBoYXNu4oCZdCBwcm9ncmVzc2VkIHlldCAocG9zc2libGUg ZXh0cmEgY2hhbmdlcyBuZWVkZWQNCmVsc2V3aGVyZSkuIFJlZ2FyZGxlc3Ms IHRoaXMgcGF0Y2ggY2FuIHN0YW5kIG9uIGl04oCZcyBvd24uDQoNCkFsYW4u DQoNCj4gT24gMjMgTWF5IDIwMTgsIGF0IDExOjM2LCBBbGFuIEhheXdhcmQg PEFsYW4uSGF5d2FyZEBhcm0uY29tPiB3cm90ZToNCj4gDQo+IA0KPiBUaGFu a3MgZm9yIHRoZSByZXZpZXcuDQo+IA0KPj4gT24gMjIgTWF5IDIwMTgsIGF0 IDE0OjQ2LCBQZWRybyBBbHZlcyA8cGFsdmVzQHJlZGhhdC5jb20+IHdyb3Rl Og0KPj4gDQo+PiBPbiAwNS8yMi8yMDE4IDEyOjAwIFBNLCBBbGFuIEhheXdh cmQgd3JvdGU6DQo+Pj4gVGhlIG1hY3JvIEVMRl9TRUNUSU9OX0lOX1NFR01F TlQgc2hvdWxkIGJlIHVzZWQgd2hlbiBjYWxjdWxhdGluZyBpZg0KPj4+IGEg c2VjdGlvbiBtYXBzIHRvIGEgc2VnbWVudC4NCj4+PiANCj4+PiBUaGUgYmlu dXRpbHMgcGF0Y2ggIltQQVRDSF0gVXNlIG9mZnNldHMgaW5zdGVhZCBvZiBh ZGRyZXNzZXMgaW4NCj4+PiBFTEZfU0VDVElPTl9JTl9TRUdNRU5UIiBtYWtl cyBmdXJ0aGVyIGltcHJvdmVtZW50cyB0byB0aGUgbWFjcm8uDQo+Pj4gV2hl biB0aGUgdHdvIHBhdGNoZXMgYXJlIGNvbWJpbmVkLCB0aGlzIHdpbGwgYWxs b3cgR0RCIHRvIGJlIHVzZWQNCj4+PiB0byBkZWJ1ZyBBcm0gYmFyZW1ldGFs IGJpbmFyaWVzIHByb2R1Y2VkIGJ5IHRoZSBBcm0gQ29tcGlsZXIuIFNlZQ0K Pj4+IHRoZSBiaW51dGlscyBwYXRjaCBmb3IgZnVydGhlciBkZXRhaWxzLg0K Pj4+IA0KPj4+IFJlZ2FyZGxlc3Mgb2YgQXJtIGRlYnVnZ2luZywgdGhpcyBw YXRjaCByZWR1Y2VzIGNvZGUvbG9naWMgZHVwbGljYXRpb24NCj4+PiBpbiBn ZGIuDQo+PiANCj4+IFNvdW5kcyByZWFzb25hYmxlLg0KPj4gDQo+Pj4gLS0t IGEvZ2RiL2VsZnJlYWQuYw0KPj4+ICsrKyBiL2dkYi9lbGZyZWFkLmMNCj4+ PiBAQCAtMTIwLDE3ICsxMjAsMTMgQEAgZWxmX3N5bWZpbGVfc2VnbWVudHMg KGJmZCAqYWJmZCkNCj4+PiAgZm9yIChpID0gMCwgc2VjdCA9IGFiZmQtPnNl Y3Rpb25zOyBzZWN0ICE9IE5VTEw7IGkrKywgc2VjdCA9IHNlY3QtPm5leHQp DQo+Pj4gICAgew0KPj4+ICAgICAgaW50IGo7DQo+Pj4gLSAgICAgIENPUkVf QUREUiB2bWE7DQo+Pj4gKyAgICAgIEVsZl9JbnRlcm5hbF9TaGRyICp0aGlz X2hkciA9ICYoZWxmX3NlY3Rpb25fZGF0YSAoc2VjdCktPnRoaXNfaGRyKTsN Cj4+IA0KPj4gRHJvcCB1bm5lY2Vzc2FyeSBwYXJlbnMuICANCj4+IA0KPj4g WW91IGNvdWxkIGRlZmVyIHRoaXMgY2FsbCB1bnRpbCBhZnRlciB0aGUgU0VD X0FMTE9DIGNoZWNrLg0KPiANCj4gT2suDQo+IA0KPj4gDQo+Pj4gDQo+Pj4g ICAgICBpZiAoKGJmZF9nZXRfc2VjdGlvbl9mbGFncyAoYWJmZCwgc2VjdCkg JiBTRUNfQUxMT0MpID09IDApDQo+Pj4gCWNvbnRpbnVlOw0KPj4+IA0KPj4+ IC0gICAgICB2bWEgPSBiZmRfZ2V0X3NlY3Rpb25fdm1hIChhYmZkLCBzZWN0 KTsNCj4+PiAtDQo+Pj4gICAgICBmb3IgKGogPSAwOyBqIDwgbnVtX3NlZ21l bnRzOyBqKyspDQo+Pj4gLQlpZiAoc2VnbWVudHNbal0tPnBfbWVtc3ogPiAw DQo+Pj4gLQkgICAgJiYgdm1hID49IHNlZ21lbnRzW2pdLT5wX3ZhZGRyDQo+ Pj4gLQkgICAgJiYgKHZtYSAtIHNlZ21lbnRzW2pdLT5wX3ZhZGRyKSA8IHNl Z21lbnRzW2pdLT5wX21lbXN6KQ0KPj4+ICsJaWYgRUxGX1NFQ1RJT05fSU5f U0VHTUVOVCAodGhpc19oZHIsIHNlZ21lbnRzW2pdKQ0KPj4gDQo+PiBUaGF0 IGlzIHNvbWUgb2RkLWxvb2tpbmcgQy9DKysgY29kZSwgZm9yIGFzc3VtaW5n IHRoZSBtYWNybydzDQo+PiBpbnRlcm5hbHMgYXJlIHdyYXBwZWQgaW4gcGFy ZW5zLiAgUGxlYXNlIHdyaXRlIHRoZSBtb3JlIHVzdWFsOg0KPj4gDQo+PiAJ aWYgKEVMRl9TRUNUSU9OX0lOX1NFR01FTlQgKHRoaXNfaGRyLCBzZWdtZW50 c1tqXSkpDQo+IA0KPiBOb3QgcXVpdGUgc3VyZSB3aHkgSSBkaWRu4oCZdCBz cG90IHRoYXQgd2hlbiB3cml0aW5nIGl0Lg0KPiANCj4gDQo+PiANCj4+IE9L IHdpdGggdGhvc2UgZml4ZWQuDQo+PiANCj4gDQo+IEnigJlsbCB3YWl0IHVu dGlsIHRoZSBCRkQgcGF0Y2ggaGFzIGJlZW4gYXBwcm92ZWQgYmVmb3JlIEkg cHVzaCwgYXMgdGhlcmUNCj4gaXMgYSBzbWFsbCBjaGFuY2UgdGhhdCByZXZp ZXcgd2lsbCBjYXVzZSBtZSB0byBtYWtlIGZ1cnRoZXIgY2hhbmdlcy4gV2ls bA0KPiBwb3N0IGFnYWluIGlmIEkgZG8uDQo+IA0KPiANCj4gQWxhbi4NCg0K >From gdb-patches-return-147928-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Jun 04 16:46:28 2018 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 106123 invoked by alias); 4 Jun 2018 16:46: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 106044 invoked by uid 89); 4 Jun 2018 16:46:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=joy, quotes, switched, genuinely X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jun 2018 16:46:23 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CE6E9854E2; Mon, 4 Jun 2018 16:46:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 054ED2023451; Mon, 4 Jun 2018 16:46:20 +0000 (UTC) Subject: Re: [RFA 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20180521110651.13842-1-philippe.waroquiers@skynet.be> <15ccf634-d702-d964-1ebc-19793814e0b9@redhat.com> <1527881895.1703.16.camel@skynet.be> From: Pedro Alves Message-ID: <87de48ff-494b-4837-d93a-9e048446b75c@redhat.com> Date: Mon, 04 Jun 2018 16:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1527881895.1703.16.camel@skynet.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00071.txt.bz2 Content-length: 15732 On 06/01/2018 08:38 PM, Philippe Waroquiers wrote: > On Fri, 2018-06-01 at 15:32 +0100, Pedro Alves wrote: >> Hi Philippe, >> >> I really wish I had time to play a bit more with the series >> (I really like the idea of "frame apply") and do a more in-depth >> review today, but I probably won't, so here are some quick comments. > Hello Pedro, > Thanks for these comments. > Note that this work is a re-implementation of an earlier prototype > (the 'block of commands' prototype) that a.o. added some flags and > an optional trailing COMMAND to: > backtrace [QUALIFIERS]... [FLAGS] [COUNT] [COMMAND] > Doug Evans then suggested to rather have a new "frame apply", > which this patch provides. So, the "frame apply" elegance > is "copyrighted" Doug Evans :). > :-) > When re-starting this work, I looked at the various rich different > ways GDB command parses 'flags/options/qualifiers/modifiers/...' > where "various rich different ways" is a politically correct synonym > of "mess" :). :-) > > We have at least: > * some commands have options but without -, and these options can be > abbreviated, e.g. backtrace full same as backtrace f > or backtrace fu > (this abbreviation feature seems not documented) Yes, these will tend to be very old commands / options. > * some commands have options such as -x, and use -- as option terminator > e.g. alias -a -- -myaliasfordownstartswithaminus = down > demangle [-l language] [--] name Right, newer commands started doing that. Since we don't have a generic framework, it's been done on an as-needed, or in-case-we-need-it-in-future basis. I know I pushed to add it more than once in review. > * some commands have long option that starts with a -, and cannot be > abbreviated e.g. thread apply all -ascending p 1 Right. I'd call that a bug. > * some commands have a short -a option, but accepts whatever after > e.g. (gdb) interrupt -ahboncettecommandeacceptenimportequoi LOL > * some commands have / e.g. print,x, disassemble,ptype, ... commands > For print and x, what follows / is a FMT, > while for disassemble, these are more like flag options. > > Based on the above, it is not very clear what is the > 'less unusual' usual way to specify flags/options. It should at least be clear that single-'-' is used throughout, while double-'-' like gnuopt does (by default) for long options is never used, except in the '--' terminator. The explicit location options for example, is a clear example of more modern GDB options. There, we accept "break -function", "break -line", etc. and all abbreviations, like "b -fun", "b -f", etc. And very importantly, we support TAB completion of command options. I think that's the killer feature. It helps with the typing _and_ the discoverability of the user interface. I.e., you can type "b -TAB" to see all the options you can pass to the command. I'd like to be able to have that for _all_ commands. > > In parallel, I have started another patch to have e.g. > info var [-t TYPE_REGEXP ] REGEXP > to only show the var having a type matching TYPE_REGEXP > This is showing yet another difficulty: how to put a space > in an argument ? Unless it's the last/rightmost argument, then I think the best choice is to have the user quote or escape if necessary? Note that "b -function foo (int) -line 10" works, even though there's a space in "foo (int)", because the explicit location's parser was taught to skip past function names, and in that case, we know that ()s are balanced. But it's tricky code, and the same probably can't be done for REGEXPs, I think. > > At that point, it looked like one of my next patch should > be an 'option/argument parser', basically the same as what > you describe above with the 'generic framework for command > options'. This framework should provide option parsing > and argument parsing, and allow optional quoting. > IMO, we better base this as much as possible to be > similar to the usual getopt, with at least the following > differences: > * for backward compatibility, we should support sometimes > alternative backward compatible behaviour, together with > a new 'standard behaviour' e.g. > backtrace [--full | -f | full ] .... > or > thread apply all [--ascending | -a | -ascending ] That's basically unlike any command option in GDB currently. We've settled on single-'-' a long time ago, so I'm not seeing how breaking that buys us much other than another long partial transition, lots of confusion and breaking scripts and user habits. Because we currently accept single '-' as long option specifier, I don't see how we can both keep backward compatibility with current "b -function" etc, _and_ allow single '-' as specifier for short-options-that-can-be-combined, because that causes ambiguity like, what does "(gdb) cmd -fu" mean: #1 - (gdb) cmd -function #2 - (gdb) cmd -function -unique ? I don't think that saying 'it's "-function" if "-unique" doesn't exist yet', because then we need worry about the fact that adding any option can break any abbreviated use of existing options. > * have -- systematically allowing to terminate options *nod* > (if we go for /, then should // terminate options then?) > * have a way to (explicitely) quote an argument e.g. > info var -Qt 'long int' regexpofsomevars > where -Q indicates that the next "value argument" is > explicitely quoted. Not sure we need that -Q. We can support optional quotes, and tell users to add quotes if necessary? That's what we've done since forever in linespecs and expressions, for example. > * allow combining short one letter args such as -cs > but also allow -c -s I think that way lies madness. > * support (at least for disassemble/ptype/..., maybe not > for FMT that would still be only like it is now) the > /x backward compatible form, but provide also new > 'standard' options e.g.  > disassemble [-m | /m | --mixed] [-s | /s | --source] ... > * common behaviour of such option/arg parsing should be centrally > documented, in particular quoting, abbreviation of long options, > terminating options with --, ... > * ... any other idea/needed feature ? > > What this patch gives is compatible with this (future generic > framework) option/arg parser to be developed. As mentioned above, I think the combining the short options under a single '-' is problematic. As such, I'd rather see that removed from the patch, and the flags implemented as regular individually-specified options. I.e., have the user type "-s -c" instead of "-sc". It's really not much of a difference for the user. > If we assume that > the 'long single -' option (such as -ascending) cannot be > abbreviated, I don't think that's desirable. I think making GDB support "-ascending" abbreviations would be an obviously desirable patch. > then I think we can make something backward compatible > but go to a more uniform option/arg parsing (and avoid > 'local' re-implementation of option parsing logic such as > skip spaces etc). > Of course, if in this patchn, we mandate -v -v -c -s > instead of -vvcs, that would be equally compatible with the > future option/arg parser > ('future' is the politically correct synonym of vapourware :). I resent the "vapourware" remark. :-P It's real! :-P See here: https://github.com/palves/gdb/commits/palves/cmd-options That started out with some discussions about changing the defaults of some of the "set print" options, like "set print static-members" and "set print object". It occurred to me then that part of the problem of picking defaults is that it's not possible to override the "set print" options in individual single-shot "print" command invocations. If we could do that, then the defaults are a little bit less important (though still important). So that branch wires in all the "set print FOO" toggles backed by value_print_options in the code as "print" command options, and along the way introduces a framework to make it happen: (gdb) set print [TAB] address max-symbolic-offset static-members array null-stop symbol array-indexes object symbol-filename asm-demangle pascal_static-members symbol-loading demangle pretty thread-events elements raw type entry-values raw-frame-arguments union frame-arguments repeats vtbl inferior-events sevenbit-strings (gdb) set print (gdb) print -[TAB] -address -elements -pretty -symbol -array -null-stop -repeats -union -array-indexes -object -static-members -vtbl (gdb) print - (gdb) p array $1 = {{elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}, { elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}, {elem = 1, static s = 0}} (gdb) p -static-members off array $2 = {{elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}, {elem = 1}} (gdb) p -pretty -static-members off -- array $3 = {{ elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }, { elem = 1 }} etc. I've also hooked it to a few other commands for experimentation: (gdb) bt -[TAB] -entry-values -frame-arguments -full -hide -no-filters -raw-frame-arguments (gdb) info threads [TAB] -gid THREAD_ID_LIST (gdb) thread apply all -[TAB] (gdb) thread apply all -ascending # there are no other options currently (gdb) help print Print value of expression EXP. Usage: print [[OPTION]... --] [EXP] Variables accessible are those of the lexical environment of the selected stack frame, plus all those whose scope is global or an entire file. Options: -address [on|off] Set printing of addresses. -array [on|off] Set pretty formatting of arrays. -array-indexes [on|off] Set printing of array indexes. -elements NUMBER | unlimited Set limit on string chars or array elements to print. "unlimited" causes there to be no limit. -null-stop [on|off] Set printing of char arrays to stop at first null char. -object [on|off] Set printing of C++ virtual function tables. -pretty [on|off] Set pretty formatting of structures. -repeats NUMBER | unlimited Set threshold for repeated print elements. "unlimited" causes all elements to be individually printed. -static-members [on|off] Set printing of C++ static members. -symbol [on|off] Set printing of symbol names when printing pointers. -union [on|off] Set printing of unions interior to structures. -vtbl [on|off] Set printing of C++ virtual function tables. [...] (gdb) I rebased that branch this weekend and played with it a bit more, but there's still a lot to do. In particular, the internal API grew organically as I threw new commands and use cases at it, and I wouldn't call it final. To reiterate, a couple design goals played into its current form: #1 - desire to have normal parsing and completion take most of the same code paths, so that we avoid normal parsing and completion parsing going out of sync. This is a continuation of the same idea that I used for the linespec parser rework from last year. #2 - share options / data structures with "set/show" command options parsing. I wrote most of this about 6 months ago, and haven't context switched it all back in, but I think I wanted to look to see if we could share more for point #2 above. I encourage you (and others) to give it a try, particularly play with TAB completion, see how that makes options more discoverable and the CLI a better joy. IMO. (and I think we could do a lot of neat things with completion, like maybe display the completion matches in one column, and option usage in another column, all in the same display. And color!) > > So, in summary, from my point of view, in the future, > we better go for something getopt compatible, and have > backward compatibility for the existing flags/modifier, > and so have -FLAGS in this patch rather than /FLAGS. > >>> Th new command 'frame apply' allows to apply a COMMAND to a number of frames, >>> or to all frames. >>> The optional -FLAGS... argument allows to control what output to produce >>> and how to handle errors raised when applying COMMAND to a frame. >>> >>> Some examples usages for this new command: >>> frame apply all info frame >>> Produce info frame for all frames >>> frame apply all p $sp >>> For each frame, print the location, followed by the frame sp >>> frame apply all -qq p $sp >>> Same as before, but -qq flags (q = quiet) indicate to only print >>> the frames sp. >>> frame apply all -vv p $sp >>> Same as before, but -vv flags (v = verbose) indicate to print >>> location and source line for each frame. >>> frame apply all p some_local_var_somewhere >>> Print some_local_var_somewhere in all frames. 'frame apply' >>> will abort as soon as the print command fails. >>> frame apply all -c p some_local_var_somewhere >>> Same as before, but -c flag (c = continue) means to >>> print the error and continue applying command in case the >>> print command fails. >>> frame apply all -s p some_local_var_somewhere >>> Same as before, but -s flag (s = silent) means to >>> be silent for frames where the print command fails. >>> In other words, this allows to 'search' the frame in which >>> some_local_var_somewhere can be printed. >>> >>> 'thread apply' command has been enhanced to also accepts a -FLAGS... >>> argument. >>> >>> Some examples usages for this new argument: >>> thread apply all -s frame apply all -s p some_local_var_somewhere >>> Prints the thread id, frame location and some_local_var_somewhere >>> value in frames of threads that have such local var. >>> >>> To make the life of the user easier, the most typical use cases >>> have shortcuts : >>> faas : shortcut for 'frame apply all -s' >>> taas : shortcut for 'thread apply all -s' >>> tfaas : shortcut for 'thread apply all -s frame apply all -s" >> I'm not particularly sold on adding aliases, since you can >> abbreviate and tab-complete. Users are used to "t a a", >> for example, so I think "f a a" will come naturally, and >> users can add aliases themselves with the "alias" command. >> But that may be because I haven't played with the patches much yet. > I could not make an alias that was specifying -s or any option, > e.g. > (gdb) alias inta = interrupt -a > Invalid command to alias to: interrupt -a > (gdb) That sounds like something we should fix, regardless. > and I found e.g. > t a a -s f a a -s  > quite long to type, and so worth the aliases. I wonder whether that's a real use case in practice though. What sort of thing does one want to print in all frames of all threads? Genuinely curious. >   >>> An example usage : >>> tfaas p some_local_var_somewhere >>> same as the longer: >>> 'thread apply all -s frame apply all -s p some_local_var_somewhere' I could bite that, even though it looks a bit contrived to me. Thanks, Pedro Alves