From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29538 invoked by alias); 22 Mar 2019 12:06:08 -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 29525 invoked by uid 89); 22 Mar 2019 12:06:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.5 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.1 spammy=5018 X-HELO: EUR04-VI1-obe.outbound.protection.outlook.com Received: from mail-eopbgr80040.outbound.protection.outlook.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (40.107.8.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Mar 2019 12:06:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wm9mk9mHqic16IhwMS6F5Es13FF1Kjnqt7qi5Nye70A=; b=QwBZ2oM97GpAsofCnUgvZkAQhEmV7CNFzdRSI6Fb1ruAEyrbZhCWKa5D35R+8SVhUxbRDqWnPdlO4XkHP3MrtIaRE7TyNRKGDZ/+ye2Ua8p7PmYdWW79Ya1xG2iJaledVLtilWFaP21jAXAmHpqcT3PBouHZSeUg3e83QZYqyDw= Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.227.22) by DB6PR0802MB2216.eurprd08.prod.outlook.com (10.172.227.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Fri, 22 Mar 2019 12:06:02 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::2083:2d62:84fa:a547]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::2083:2d62:84fa:a547%3]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 12:06:02 +0000 From: Alan Hayward To: Simon Marchi CC: "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH v2 2/8] AArch64: Use HWCAP to detect pauth feature Date: Fri, 22 Mar 2019 12:06:00 -0000 Message-ID: <2D3B7D5F-55C6-40B4-A84C-29139BD18208@arm.com> References: <20190306133325.2531-1-alan.hayward@arm.com> <20190306133325.2531-3-alan.hayward@arm.com> In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 Content-Type: text/plain; charset="utf-8" Content-ID: <1E603B95F33AF44C9AC41D628DF2D771@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00483.txt.bz2 DQoNCj4gT24gMjEgTWFyIDIwMTksIGF0IDIwOjUwLCBTaW1vbiBNYXJjaGkg PHNpbWFya0BzaW1hcmsuY2E+IHdyb3RlOg0KPiANCj4gT24gMjAxOS0wMy0w NiA4OjMzIGEubS4sIEFsYW4gSGF5d2FyZCB3cm90ZToNCj4+IEFkZCBhYXJj aDY0X2dldF9od2NhcCBmdW5jdGlvbnMgZm9yIHJlYWRpbmcgdGhlIEhXQ0FQ Lg0KPj4gRnJvbSB0aGlzIGV4dHJhY3QgdGhlIFBBQ0EgdmFsdWUgYW5kIHVz ZSB0aGlzIHRvIGVuYWJsZSBwYXV0aC4NCj4+IGdkYi9DaGFuZ2VMb2c6DQo+ PiANCg0KPHNuaXA+DQoNCj4+ICsNCj4gDQo+IEkgZG9uJ3Qga25vdyBpZiBp dCBhY3R1YWxseSBtYXR0ZXJzLCBidXQgd2hlbiB0aGUgdGFyZ2V0X2F1eF9z ZWFyY2ggY2FsbCB3YXMgaW4gYWFyY2g2NF9saW51eF9jb3JlX3JlYWRfZGVz Y3JpcHRpb24sIGl0IHVzZWQgdGhlIFRBUkdFVCBwYXJhbWV0ZXIsIHJhdGhl ciB0aGFuIHVzaW5nIGN1cnJlbnRfdG9wX3RhcmdldC4gIFNvLCBwZXJoYXBz IHRoYXQgbmV3IGZ1bmN0aW9uIHNob3VsZCB0YWtlIGEgdGFyZ2V0X29wcyBw YXJhbWV0ZXIgYW5kIHVzZSBpdD8gIFRoZSBvdGhlciBjYWxsIGluIGFhcmNo NjRfbGludXhfbmF0X3RhcmdldDo6cmVhZF9kZXNjcmlwdGlvbiB3b3VsZCBw YXNzICJ0aGlz4oCdLg0KDQpGb3Igc2FmZXR5IEnigJl2ZSB1cGRhdGVkIGl0 IHRvIHBhc3MgdGhyb3VnaCB0aGUgdGFyZ2V0Lg0KDQo+IA0KPiBBbmQgdGhp cyBmdW5jdGlvbiBkb2VzIG5vdGhpbmcgQUFyY2g2NC1zcGVjaWZpYywgc28g SSB0aGluayBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgaXQgaW4gbGludXgt dGRlcC57aCxjfSBhbmQgdXBkYXRlIG90aGVyIGFyY2hlcyB0byB1c2UgaXQu IEJ1dCBJIHdvdWxkIHNheSwgZG9uJ3QgYm90aGVyIHdpdGggdGhhdCBpbiB0 aGlzIHNlcmllcywgd2UgY2FuIGRvIGl0IGFmdGVyLg0KPiANCj4gU2ltb24N Cg0KQWdyZWVkLiBBbmQgdGhlIGdkYnNlcnZlciB2ZXJzaW9uIHNob3VsZCBw cm9iYWJseSBiZSBtb3ZlZCBpbnRvIGNvbW1vbiBjb2RlIHRvby4gSeKAmWxs IGdldCBhIG5ldyBwYXRjaCB0b2dldGhlciBmb3IgdGhhdC4NCg0KDQpUaGFu a3MgZm9yIHRoZSByZXZpZXdzLiBQdXNoZWQgdGhlIHNlcmllcy4gVXBkYXRl ZCB2ZXJzaW9uIG9mIHRoaXMgcGF0Y2ggYmVsb3cuDQoNCg0KZGlmZiAtLWdp dCBhL2dkYi9hYXJjaDY0LWxpbnV4LW5hdC5jIGIvZ2RiL2FhcmNoNjQtbGlu dXgtbmF0LmMNCmluZGV4IGY1OGE0MWUxOTUuLjk1NzIwNTVkOWYgMTAwNjQ0 DQotLS0gYS9nZGIvYWFyY2g2NC1saW51eC1uYXQuYw0KKysrIGIvZ2RiL2Fh cmNoNjQtbGludXgtbmF0LmMNCkBAIC02MDYsOCArNjA2LDExIEBAIGFhcmNo NjRfbGludXhfbmF0X3RhcmdldDo6cmVhZF9kZXNjcmlwdGlvbiAoKQ0KICAg aWYgKHJldCA9PSAwKQ0KICAgICByZXR1cm4gdGRlc2NfYXJtX3dpdGhfbmVv bjsNCg0KLSAgLyogcGF1dGggbm90IHlldCBzdXBwb3J0ZWQuICAqLw0KLSAg cmV0dXJuIGFhcmNoNjRfcmVhZF9kZXNjcmlwdGlvbiAoYWFyY2g2NF9zdmVf Z2V0X3ZxICh0aWQpLCBmYWxzZSk7DQorICBDT1JFX0FERFIgaHdjYXAgPSAw Ow0KKyAgYm9vbCBwYXV0aF9wID0gYWFyY2g2NF9saW51eF9nZXRfaHdjYXAg KHRoaXMsICZod2NhcCkNCisgICAgICAgICAgICAgICAgJiYgKGh3Y2FwICYg QUFSQ0g2NF9IV0NBUF9QQUNBKTsNCisNCisgIHJldHVybiBhYXJjaDY0X3Jl YWRfZGVzY3JpcHRpb24gKGFhcmNoNjRfc3ZlX2dldF92cSAodGlkKSwgcGF1 dGhfcCk7DQogfQ0KDQogLyogQ29udmVydCBhIG5hdGl2ZS9ob3N0IHNpZ2lu Zm8gb2JqZWN0LCBpbnRvL2Zyb20gdGhlIHNpZ2luZm8gaW4gdGhlDQpkaWZm IC0tZ2l0IGEvZ2RiL2FhcmNoNjQtbGludXgtdGRlcC5jIGIvZ2RiL2FhcmNo NjQtbGludXgtdGRlcC5jDQppbmRleCA0NDUwMTlhY2NjLi5kN2RiMjNlZjM4 IDEwMDY0NA0KLS0tIGEvZ2RiL2FhcmNoNjQtbGludXgtdGRlcC5jDQorKysg Yi9nZGIvYWFyY2g2NC1saW51eC10ZGVwLmMNCkBAIC02MzcsMTIgKzYzNywx MSBAQCBhYXJjaDY0X2xpbnV4X2NvcmVfcmVhZF9kZXNjcmlwdGlvbiAoc3Ry dWN0IGdkYmFyY2ggKmdkYmFyY2gsDQogew0KICAgQ09SRV9BRERSIGFhcmNo NjRfaHdjYXAgPSAwOw0KDQotICBpZiAodGFyZ2V0X2F1eHZfc2VhcmNoICh0 YXJnZXQsIEFUX0hXQ0FQLCAmYWFyY2g2NF9od2NhcCkgIT0gMSkNCi0gICAg cmV0dXJuIE5VTEw7DQorICBpZiAoIWFhcmNoNjRfbGludXhfZ2V0X2h3Y2Fw ICh0YXJnZXQsICZhYXJjaDY0X2h3Y2FwKSkNCisgICAgcmV0dXJuIG51bGxw dHI7DQoNCi0gIC8qIHBhdXRoIG5vdCB5ZXQgc3VwcG9ydGVkLiAgKi8NCiAg IHJldHVybiBhYXJjaDY0X3JlYWRfZGVzY3JpcHRpb24gKGFhcmNoNjRfbGlu dXhfY29yZV9yZWFkX3ZxIChnZGJhcmNoLCBhYmZkKSwNCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZmFsc2UpOw0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhYXJjaDY0X2h3Y2FwICYgQUFSQ0g2 NF9IV0NBUF9QQUNBKTsNCiB9DQoNCiAvKiBJbXBsZW1lbnRhdGlvbiBvZiBg Z2RiYXJjaF9zdGFwX2lzX3NpbmdsZV9vcGVyYW5kJywgYXMgZGVmaW5lZCBp bg0KQEAgLTE0MjAsNiArMTQxOSwxNSBAQCBhYXJjaDY0X2xpbnV4X2djY190 YXJnZXRfb3B0aW9ucyAoc3RydWN0IGdkYmFyY2ggKmdkYmFyY2gpDQogICBy ZXR1cm4gTlVMTDsNCiB9DQoNCisvKiBTZWUgYWFyY2g2NC1saW51eC10ZGVw LmguICAqLw0KKw0KK2Jvb2wNCithYXJjaDY0X2xpbnV4X2dldF9od2NhcCAo c3RydWN0IHRhcmdldF9vcHMgKnRhcmdldCwgQ09SRV9BRERSICpod2NhcCkN Cit7DQorICAqaHdjYXAgPSAwOw0KKyAgcmV0dXJuIHRhcmdldF9hdXh2X3Nl YXJjaCAodGFyZ2V0LCBBVF9IV0NBUCwgaHdjYXApID09IDE7DQorfQ0KKw0K IHN0YXRpYyB2b2lkDQogYWFyY2g2NF9saW51eF9pbml0X2FiaSAoc3RydWN0 IGdkYmFyY2hfaW5mbyBpbmZvLCBzdHJ1Y3QgZ2RiYXJjaCAqZ2RiYXJjaCkN CiB7DQpkaWZmIC0tZ2l0IGEvZ2RiL2FhcmNoNjQtbGludXgtdGRlcC5oIGIv Z2RiL2FhcmNoNjQtbGludXgtdGRlcC5oDQppbmRleCA4MTQyMjJlYWQwLi5l OWY3YzliY2NmIDEwMDY0NA0KLS0tIGEvZ2RiL2FhcmNoNjQtbGludXgtdGRl cC5oDQorKysgYi9nZGIvYWFyY2g2NC1saW51eC10ZGVwLmgNCkBAIC0zNiw0 ICszNiwxMCBAQA0KIGV4dGVybiBjb25zdCBzdHJ1Y3QgcmVnc2V0IGFhcmNo NjRfbGludXhfZ3JlZ3NldDsNCiBleHRlcm4gY29uc3Qgc3RydWN0IHJlZ3Nl dCBhYXJjaDY0X2xpbnV4X2ZwcmVnc2V0Ow0KDQorLyogTWF0Y2hlcyBIV0NB UF9QQUNBIGluIGtlcm5lbCBoZWFkZXIgYXJjaC9hcm02NC9pbmNsdWRlL3Vh cGkvYXNtL2h3Y2FwLmguICAqLw0KKyNkZWZpbmUgQUFSQ0g2NF9IV0NBUF9Q QUNBICgxIDw8IDMwKQ0KKw0KKy8qIEZldGNoIHRoZSBBVF9IV0NBUCBlbnRy eSBmcm9tIHRoZSBhdXh2IHZlY3RvciBmb3IgdGhlIGdpdmVuIFRBUkdFVC4g ICovDQorYm9vbCBhYXJjaDY0X2xpbnV4X2dldF9od2NhcCAoc3RydWN0IHRh cmdldF9vcHMgKnRhcmdldCwgQ09SRV9BRERSICpod2NhcCk7DQorDQogI2Vu ZGlmIC8qIEFBUkNINjRfTElOVVhfVERFUF9IICovDQpkaWZmIC0tZ2l0IGEv Z2RiL2dkYnNlcnZlci9saW51eC1hYXJjaDY0LWxvdy5jIGIvZ2RiL2dkYnNl cnZlci9saW51eC1hYXJjaDY0LWxvdy5jDQppbmRleCBkYjMyOWRhNGRjLi5l MmUyNWYwZTI3IDEwMDY0NA0KLS0tIGEvZ2RiL2dkYnNlcnZlci9saW51eC1h YXJjaDY0LWxvdy5jDQorKysgYi9nZGIvZ2Ric2VydmVyL2xpbnV4LWFhcmNo NjQtbG93LmMNCkBAIC00ODUsNiArNDg1LDMzIEBAIGFhcmNoNjRfbGludXhf bmV3X2ZvcmsgKHN0cnVjdCBwcm9jZXNzX2luZm8gKnBhcmVudCwNCiAgICpj aGlsZC0+cHJpdi0+YXJjaF9wcml2YXRlID0gKnBhcmVudC0+cHJpdi0+YXJj aF9wcml2YXRlOw0KIH0NCg0KKy8qIE1hdGNoZXMgSFdDQVBfUEFDQSBpbiBr ZXJuZWwgaGVhZGVyIGFyY2gvYXJtNjQvaW5jbHVkZS91YXBpL2FzbS9od2Nh cC5oLiAgKi8NCisjZGVmaW5lIEFBUkNINjRfSFdDQVBfUEFDQSAoMSA8PCAz MCkNCisNCisvKiBGZXRjaCB0aGUgQVRfSFdDQVAgZW50cnkgZnJvbSB0aGUg YXV4diB2ZWN0b3IuICAqLw0KKw0KK3N0YXRpYyBib29sDQorYWFyY2g2NF9n ZXRfaHdjYXAgKHVuc2lnbmVkIGxvbmcgKnZhbHApDQorew0KKyAgdW5zaWdu ZWQgY2hhciAqZGF0YSA9ICh1bnNpZ25lZCBjaGFyICopIGFsbG9jYSAoMTYp Ow0KKyAgaW50IG9mZnNldCA9IDA7DQorDQorICB3aGlsZSAoKCp0aGVfdGFy Z2V0LT5yZWFkX2F1eHYpIChvZmZzZXQsIGRhdGEsIDE2KSA9PSAxNikNCisg ICAgew0KKyAgICAgIHVuc2lnbmVkIGxvbmcgKmRhdGFfcCA9ICh1bnNpZ25l ZCBsb25nICopZGF0YTsNCisgICAgICBpZiAoZGF0YV9wWzBdID09IEFUX0hX Q0FQKQ0KKyAgICAgICB7DQorICAgICAgICAgKnZhbHAgPSBkYXRhX3BbMV07 DQorICAgICAgICAgcmV0dXJuIHRydWU7DQorICAgICAgIH0NCisNCisgICAg ICBvZmZzZXQgKz0gMTY7DQorICAgIH0NCisNCisgICp2YWxwID0gMDsNCisg IHJldHVybiBmYWxzZTsNCit9DQorDQogLyogSW1wbGVtZW50YXRpb24gb2Yg bGludXhfdGFyZ2V0X29wcyBtZXRob2QgImFyY2hfc2V0dXAiLiAgKi8NCg0K IHN0YXRpYyB2b2lkDQpAQCAtNTAxLDggKzUyOCwxMCBAQCBhYXJjaDY0X2Fy Y2hfc2V0dXAgKHZvaWQpDQogICBpZiAoaXNfZWxmNjQpDQogICAgIHsNCiAg ICAgICB1aW50NjRfdCB2cSA9IGFhcmNoNjRfc3ZlX2dldF92cSAodGlkKTsN Ci0gICAgICAvKiBwYXV0aCBub3QgeWV0IHN1cHBvcnRlZC4gICovDQotICAg ICAgY3VycmVudF9wcm9jZXNzICgpLT50ZGVzYyA9IGFhcmNoNjRfbGludXhf cmVhZF9kZXNjcmlwdGlvbiAodnEsIGZhbHNlKTsNCisgICAgICB1bnNpZ25l ZCBsb25nIGh3Y2FwID0gMDsNCisgICAgICBib29sIHBhdXRoX3AgPSBhYXJj aDY0X2dldF9od2NhcCAoJmh3Y2FwKSAmJiAoaHdjYXAgJiBBQVJDSDY0X0hX Q0FQX1BBQ0EpOw0KKw0KKyAgICAgIGN1cnJlbnRfcHJvY2VzcyAoKS0+dGRl c2MgPSBhYXJjaDY0X2xpbnV4X3JlYWRfZGVzY3JpcHRpb24gKHZxLCBwYXV0 aF9wKTsNCiAgICAgfQ0KICAgZWxzZQ0KICAgICBjdXJyZW50X3Byb2Nlc3Mg KCktPnRkZXNjID0gdGRlc2NfYXJtX3dpdGhfbmVvbjs= >From gdb-patches-return-154796-listarch-gdb-patches=sources.redhat.com@sourceware.org Fri Mar 22 12:39:40 2019 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 83708 invoked by alias); 22 Mar 2019 12:39:40 -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 83412 invoked by uid 89); 22 Mar 2019 12:39:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=franco, Franco, hang, WDYT X-HELO: mail-wr1-f52.google.com Received: from mail-wr1-f52.google.com (HELO mail-wr1-f52.google.com) (209.85.221.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Mar 2019 12:39:37 +0000 Received: by mail-wr1-f52.google.com with SMTP id w1so2212067wrp.2 for ; Fri, 22 Mar 2019 05:39:37 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id q17sm6622649wrx.38.2019.03.22.05.39.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 05:39:34 -0700 (PDT) Subject: [PATCH] Fix testsuite hangs when gdb_test_multiple body errors out (Re: GDB 8.2.90 available for testing) To: Pedro Franco de Carvalho , Joel Brobecker , gdb-patches@sourceware.org References: <20190227055112.4A5E782D7B@joel.gnat.com> <8736ny7f8u.fsf@linux.vnet.ibm.com> From: Pedro Alves Message-ID: <4d855905-32ce-ba4b-72f5-037f1796b37e@redhat.com> Date: Fri, 22 Mar 2019 12:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8736ny7f8u.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00484.txt.bz2 Content-length: 6840 Hi Pedro, Thanks for the detailed report. On 03/07/2019 05:42 PM, Pedro Franco de Carvalho wrote: > I'm not sure if there is a proper way to work around this in GDB, but it > would be useful so that the testsuite doesn't hang in these cases. I spent a while trying to fix this, and I came up with the patch below. WDYT? >From 17e8f28072cce040524eab7b85b8767764a54cd2 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Fri, 22 Mar 2019 11:33:19 +0000 Subject: [PATCH] Fix testsuite hangs when gdb_test_multiple body errors out This commit fixes a regression in the testsuite itself, triggered by errors being raised from within gdb_test_multiple, originally reported by Pedro Franco de Carvalho's at . Parts of the commit message are based on his report. This started happening due to a commit that was introduced recently, and it can cause the testsuite to hang. The commit that triggers this is: fe1a5cad302b5535030cdf62895e79512713d738 [gdb/testsuite] Log wait status on process no longer exists error That commit introduces a new "eof" block in gdb_test_multiple. That is not incorrect itself, but dejagnu's remote_expect is picking that block as the "default" action when an error is raised from within the commands inside a call to gdb_test_multiple: # remote_expect works basically the same as standard expect, but it # also takes care of getting the file descriptor from the specified # host and also calling the timeout/eof/default section if there is an # error on the expect call. # proc remote_expect { board timeout args } { I find that "feature" surprising, and I don't really know why it exists, but this means that the eof section that remote_expect picks as the error block can be executed even when there was no actual eof and the GDB process is still running, so the wait introduced in the commit that tries to get the exit status of GDB hangs forever, while GDB itself waits for input. This only happens when there are internal testsuite errors (not testcase failures). This can be reproduced easily with a testcase such as: gdb_start gdb_test_multiple "show version" "show version" { -re ".*" { error "forced error" } } I think that working around this in GDB is useful so that the testsuite doesn't hang in these cases. Adding an empty "default" block at the end of the expect body in gdb_test_multiple doesn't work, because dejagnu gives preference to "eof" blocks: if { $x eq "eof" } { set save_next 1 } elseif { $x eq "default" || $x eq "timeout" } { if { $error_sect eq "" } { set save_next 1 } } And we do have "eof" blocks. So we need to make sure that the last "eof" block is safe to use as the default error block. It's also pedantically incorrect to print "ERROR: Process no longer exists" which is what we'd get if the last eof block we have was selected (more below on this). So this commit solves this by appending an "eof" with an empty spawn_id list, so that it won't ever match. Now, why is the first "eof" block selected today as the error block, instead of the last one? The reason is that remote_expect, while parsing the body to select the default block to execute after an error, is affected by the comments in the body (since they are also parsed). If this comment in gdb_test_multiple # patterns below apply to any spawn id specified. is changed to # The patterns below apply to any spawn id specified. then the second eof block is selected and there is no hang. Any comment at that same place with an even-numbered of tokens also works. This is IMO a coincidence caused by how comments work in TCL. Comments should only appear in places where a command can appear. And here, remote_expect is parsing a list of options, not commands, so it's not unreasonable to not parse comments, similarly to how this: set a_list { an_element # another_element } results in a list with three elements, not one element. The fact that comments with an even number of tokens work is just a coincidence of how remote_expect's little state machine is implemented. I thought we could solve this by stripping out comment lines in gdb_expect, but I didn't find an easy way to do that. Particularly, a couple naive approaches I tried run into complications. For example, we have gdb_test calls with regular expressions that include sequences like "\r\n#", and by the time we get to gdb_expect, the \r\n have already been expanded to a real newline, so just splitting the whole body at newline boundaries, looking for lines that start with # results in incorrectly stripping out half of the gdb_text regexp. I think it's better (at least in this commit), to move the comments out of the list, because it's much simpler and risk free. gdb/ChangeLog: yyyy-mm-dd Pedro Alves * lib/gdb.exp (gdb_test_multiple): Split appends to $code and move comments outside list. Append '-i "" eof' section. --- gdb/testsuite/lib/gdb.exp | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 6800c74187..4600d2c347 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -906,10 +906,13 @@ proc gdb_test_multiple { command message user_code } { } } append code $processed_code + + # Reset the spawn id, in case the processed code used -i. append code { - # Reset the spawn id, in case the processed code used -i. -i "$gdb_spawn_id" + } + append code { -re "Ending remote debugging.*$gdb_prompt $" { if ![isnative] then { warning "Can`t communicate to remote target." @@ -990,8 +993,10 @@ proc gdb_test_multiple { command message user_code } { } return -1 } + } - # Patterns below apply to any spawn id specified. + # Now patterns that apply to any spawn id specified. + append code { -i $any_spawn_id eof { perror "Process no longer exists" @@ -1013,6 +1018,20 @@ proc gdb_test_multiple { command message user_code } { } } + # remote_expect calls the eof section if there is an error on the + # expect call. We already have "eof" sections above, and we don't + # want them to get called in that situation. Since the last "eof" + # section becomes the error section, here we define another "eof" + # section, but with an empty spawn_id list, so that it won't ever + # match anything. + append code { + -i "" eof { + # This comment is here because the eof section must not be + # the empty string, otherwise remote_expect won't realize + # it exists. + } + } + set result 0 set code [catch {gdb_expect $code} string] if {$code == 1} { -- 2.14.4