From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106815 invoked by alias); 29 Oct 2018 11:58:32 -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 106777 invoked by uid 89); 29 Oct 2018 11:58:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=(unknown), resolving, Hx-languages-length:2925, itd X-HELO: EUR03-DB5-obe.outbound.protection.outlook.com Received: from mail-eopbgr40086.outbound.protection.outlook.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (40.107.4.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Oct 2018 11:58:28 +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=yiDH2gH910J8gkMs+lRTlMdKzu3Grw+a7ZiO9Az8WH4=; b=FGjadpCYBlzSF3bXJ2Ew7uDCrlJlU5bfC0rzwX9pu/8F4w77wvem7ZrFg8rEha0eIWibXXV6z3XjApa9F7i0uy69oDzzPvO7ey4XSceTjmK6QzgcaHpl/pWWiCaPsj9JC9w4qGX2d5qR60TjCtGKfW60QAE3NvBMJeCN1rjm8Og= Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.226.148) by DB6PR0802MB2214.eurprd08.prod.outlook.com (10.172.227.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.19; Mon, 29 Oct 2018 11:58:25 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11%7]) with mapi id 15.20.1273.027; Mon, 29 Oct 2018 11:58:25 +0000 From: Alan Hayward To: Pedro Alves CC: GDB Patches , nd Subject: Re: [PATCH v3 3/3] Aarch64: Fix segfault when casting dummy calls Date: Mon, 29 Oct 2018 11:58:00 -0000 Message-ID: <3FFDA486-3FC8-4DA2-92C9-83C320F589F6@arm.com> References: <20181011144905.66908-1-alan.hayward@arm.com> <20181011144905.66908-4-alan.hayward@arm.com> <95a5dd34-6815-f3f5-107c-13f4956b741e@redhat.com> <9290BC71-862C-48B1-97FD-A46C5D15A65C@arm.com> <201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com> In-Reply-To: <201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com> 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) Content-Type: text/plain; charset="utf-8" Content-ID: <654C6C2CC55B174D822784CEE3669B73@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00688.txt.bz2 DQoNCj4gT24gMjQgT2N0IDIwMTgsIGF0IDE2OjE0LCBQZWRybyBBbHZlcyA8 cGFsdmVzQHJlZGhhdC5jb20+IHdyb3RlOg0KPiANCj4+IA0KPj4+IA0KPj4+ IEFuZCB3aGF0IGRvZXMgInRvIGVuc3VyZSBGVU5DIHJlc29sdmluZyIgbWVh biB0b28sIGJ0dz8NCj4+PiBBRkFJQ1QsIHRoZSBvbmx5IHJlYXNvbiB0byB1 c2UgYSBzaGFyZWQgbGlicmFyeSBpcyB0bw0KPj4+IGNvbXBpbGUgaXQgd2l0 aCBvciB3aXRob3V0IGRlYnVnIGluZm9ybWF0aW9uLCByaWdodD8NCj4+PiBD b21lIHRvIHRoaW5rIG9mIGl0LCB5b3UgY291bGQgaW5zdGVhZCBlbGltaW5h dGUgdGhlDQo+Pj4gc2hhcmVkIGxpYnJhcnkgYW5kIGNvbXBpbGUgYSBzZXBh cmF0ZSAubyBmaWxlIGluc3RlYWQsIHJpZ2h0Pw0KPj4+IFRoYXQgd291bGQg c2ltcGxpZnkgdGhlIHRlc3RjYXNlIGEgYml0IGFuZCBleHBvc2UgaXQgdG8g bW9yZQ0KPj4+IHRhcmdldHMuDQo+Pj4gDQo+PiANCj4+IEkgY291bGQgb25s eSBnZXQgdGhlIGJ1ZyB0byBleHBvc2UgaXRzZWxmIHdoZW4gdXNpbmcgYSAu c28NCj4+IA0KPj4gSWYgSSBkbyB0aGUgZm9sbG93aW5nIHVzaW5nIGN1cnJl bnQgSEVBRCB0aGVuIHRoZSBidWcgaXMgbm90IHByZXNlbnQ6DQo+PiANCj4+ IGcrKyAtYyBjb25kYnJlYWstc29saWItbWFpbi5jYyAtbyBjb25kYnJlYWst c29saWItbWFpbi5vIC1mbm8taW5saW5lDQo+PiBnKysgLWMgY29uZGJyZWFr LXNvbGliLWxpYi5jYyAtbyBjb25kYnJlYWstc29saWItbGliLm8gLWZuby1p bmxpbmUNCj4+IGcrKyBjb25kYnJlYWstc29saWItbWFpbi5vIGNvbmRicmVh ay1zb2xpYi1saWIubw0KPj4gDQo+PiBJdCBjYXVzZXMgdGhlIHR5cGUgb2Yg dGhlIHJldHVybiB2YWx1ZSB0byBiZSBkZXRlY3RlZCBhcw0KPj4gVFlQRV9D T0RFX1BUUi0+VFlQRV9DT0RFX0lOVC4NCj4gDQo+IEh1aC4gIFRoYXQncyBy ZWFsbHkgc3RyYW5nZS4gIFdoZXJlIGlzIHRoYXQgcG9pbnRlciBjb21pbmcg ZnJvbT8NCj4gDQo+IFdoYXQgZG9lcyAicHR5cGUgY21wMyIgc2F5IGZvciB5 b3U/DQo+IA0KPiAoZ2RiKSBiIGZvbyBpZiAoaW50KWNtcDMoImFiYyIpID09 IDENCj4gQnJlYWtwb2ludCAxIGF0IDB4NDAwNDhiDQo+IChnZGIpIHB0eXBl IGNtcDMNCj4gdHlwZSA9IDx1bmtub3duIHJldHVybiB0eXBlPiAoKQ0KPiAo Z2RiKSB3aGF0aXMgY21wMw0KPiB0eXBlID0gPHRleHQgdmFyaWFibGUsIG5v IGRlYnVnIGluZm8+DQo+IA0KDQpZZXMsIEkgZ2V0IHRoZSBzYW1lLg0KDQpT b3VuZHMgdG8gbWUgbGlrZSB0aGVyZSBtaWdodCBzdGlsbCBiZSBhbiBpc3N1 ZSBpbiBnZGI/IE9yIGF0IGxlYXN0DQphIGRpZmZlcmVuY2UgaW4gdGhlIHdh eSB0aGUgdHlwZSBpcyBjYWxjdWxhdGVkLg0KVGhpcyBvbiBpdOKAmXMgb3du IGlzIHN0aWxsIGEgZ29vZCBmaXgsIHNvIEnigJlsbCBzZW5kIGEgbmV3IHZl cnNpb24uDQoNCg0KPiBJIHdvbmRlciBpZiB3aGF0IHlvdSdyZSBsb29raW5n IGF0IGlzIGFjdHVhbGx5IHRoZSBtYWxsb2MgY2FsbD8NCj4gR0RCIHdpbGwg Y2FsbCBtYWxsb2MgdG8gYWxsb2NhdGUgc3BhY2UgZm9yIHRoZSAiYWJjIiBz dHJpbmcgaW4NCj4gdGhlIGluZmVyaW9yLiAgTG9vayBhdCB0aGUgYmFja3Ry YWNlLCBzZWUgd2hlcmUgdGhlIGNhbGwgaXMgY29taW5nDQo+IGZyb20uDQoN Cg0KV2l0aCB0aGUgbm9kZWJ1ZyBhbmQgZGVidWcgc2hhcmVkIGxpYnJhcnkg dmVyc2lvbjoNCihJIG5lZWQgdG8gcnVuIHRvIG1haW4gYmVmb3JlIEkgY2Fu IHNldCBicmVha3BvaW50IG9uIGNtcDMsIG90aGVyd2lzZQ0KIkZ1bmN0aW9u ICJjbXAzIiBub3QgZGVmaW5lZC7igJ0pDQoNCkJ1dCB3aXRoIGFsbCB2ZXJz aW9ucywgd2hlbiBzdG9wcGVkIGF0IGNtcDMsIEkgZ2V0Og0KKGdkYikgYnQN CiMwICAweDAwMDAwMDAwMDA0MDA1ZDQgaW4gY21wMyhjaGFyIGNvbnN0Kikg KCkNCiMxICA8ZnVuY3Rpb24gY2FsbGVkIGZyb20gZ2RiPg0KIzIgIDB4MDAw MDAwMDAwMDQwMDVhNCBpbiBmb28oKSAoKQ0KIzMgIDB4MDAwMDAwMDAwMDQw MDViYyBpbiBtYWluICgpDQoNCj4gDQo+IEFjdHVhbGx5LCBiZWNhdXNlIG9m IHRoYXQsIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIChtb3JlIGZvY3Vz ZWQpDQo+IHRvIHBhc3MgaW4gYSB2YXJpYWJsZSBpbnN0ZWFkIG9mICJhYmMi LiAgWW91IGFscmVhZHkgaGF2ZSB0aGUNCj4gdW51c2VkIHZhcmlhYmxlICJ3 b3JkIiB0aGVyZToNCj4gDQo+IGNvbnN0IGNoYXIgKndvcmQgPSAic3R1ZmYi Ow0KPiANCj4gU286DQo+IA0KPiAoZ2RiKSBiIGZvbyBpZiAoaW50KWNtcDMo d29yZCkgPT0gMQ0KPiANCj4gYnV0IHBsZWFzZSByZW5hbWUgaXQgdG8gc29t ZXRoaW5nIGVsc2UsIGJlY2F1c2UgSSB0cmllZCB0aGF0DQo+IGxvY2FsbHkg YW5kIHRoZXJlJ3MgYW5vdGhlciBzeW1ib2wgY2FsbGVkICJ3b3JkIg0KPiBp biBnbGliYydzIGxvY2FsZWluZm8uaCwgYW5kIGdkYiBwaWNrcyB0aGF0IG9u ZSB1cC4NCg0KV2lsbCBkby4NClVzaW5nIHRoaXMgc3RpbGwgY2F1c2VzIHRo ZSBidWcgaW4gSEVBRCwgc28gdGhhdOKAmXMgb2suDQoNCg0KPiANCj4gQWxz bywgaXMgdGhlcmUgYSByZWFzb24gZm9yIHRoZSB0ZXN0IHRvIGJlIGEgQysr IHByb2dyYW0/DQo+IElmIHRoZXJlJ3Mgbm9uZSwgaXQnZCBiZSBiZXR0ZXIg dG8gbWFrZSBpdCBhIEMgcHJvZ3JhbSwgYWdhaW4NCj4gdG8gZXhwb3NlIGl0 IHRvIG1vcmUgdGFyZ2V0cy4NCg0KDQpTd2l0Y2hpbmcgdG8gQyBjYXVzZXMg dGhlIGJ1ZyB0byB2YW5pc2guDQpUaGlzIGlzIGJlY2F1c2UgQysrIHVzZXMg Z251djNfcGFzc19ieV9yZWZlcmVuY2UoKSwgYW5kIHRoZQ0Kc2VnZmF1bHQg aGFwcGVucyBpbnNpZGUgdGhlcmUsIHdoZXJlYXMgQyB1c2VzDQpkZWZhdWx0 X3Bhc3NfYnlfcmVmZXJlbmNlKCksIHdoaWNoIGp1c3QgcmV0dXJucyAwLg0K DQpJ4oCZbGwgZXhwYW5kIHRoZSB0ZXN0IHRvIGNvdmVyIGJvdGggQyBhbmQg QysrLg0KDQoNCkFsYW4u >From gdb-patches-return-151971-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Oct 29 12:38:09 2018 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 89624 invoked by alias); 29 Oct 2018 12:38:09 -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 89605 invoked by uid 89); 29 Oct 2018 12:38:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hayward, hayward 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 ESMTP; Mon, 29 Oct 2018 12:38:06 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A001DC051676; Mon, 29 Oct 2018 12:38:05 +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 A205B60C69; Mon, 29 Oct 2018 12:38:04 +0000 (UTC) Subject: Re: [PATCH v3 3/3] Aarch64: Fix segfault when casting dummy calls To: Alan Hayward References: <20181011144905.66908-1-alan.hayward@arm.com> <20181011144905.66908-4-alan.hayward@arm.com> <95a5dd34-6815-f3f5-107c-13f4956b741e@redhat.com> <9290BC71-862C-48B1-97FD-A46C5D15A65C@arm.com> <201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com> <3FFDA486-3FC8-4DA2-92C9-83C320F589F6@arm.com> Cc: GDB Patches , nd From: Pedro Alves Message-ID: <862cf8f4-9491-a1eb-251e-6c7c1ffffa6c@redhat.com> Date: Mon, 29 Oct 2018 12:38: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: <3FFDA486-3FC8-4DA2-92C9-83C320F589F6@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-10/txt/msg00689.txt.bz2 Content-length: 3557 On 10/29/2018 11:58 AM, Alan Hayward wrote: > > >> On 24 Oct 2018, at 16:14, Pedro Alves wrote: >> >>> >>>> >>>> And what does "to ensure FUNC resolving" mean too, btw? >>>> AFAICT, the only reason to use a shared library is to >>>> compile it with or without debug information, right? >>>> Come to think of it, you could instead eliminate the >>>> shared library and compile a separate .o file instead, right? >>>> That would simplify the testcase a bit and expose it to more >>>> targets. >>>> >>> >>> I could only get the bug to expose itself when using a .so >>> >>> If I do the following using current HEAD then the bug is not present: >>> >>> g++ -c condbreak-solib-main.cc -o condbreak-solib-main.o -fno-inline >>> g++ -c condbreak-solib-lib.cc -o condbreak-solib-lib.o -fno-inline >>> g++ condbreak-solib-main.o condbreak-solib-lib.o >>> >>> It causes the type of the return value to be detected as >>> TYPE_CODE_PTR->TYPE_CODE_INT. >> >> Huh. That's really strange. Where is that pointer coming from? >> >> What does "ptype cmp3" say for you? >> >> (gdb) b foo if (int)cmp3("abc") == 1 >> Breakpoint 1 at 0x40048b >> (gdb) ptype cmp3 >> type = () >> (gdb) whatis cmp3 >> type = >> > > Yes, I get the same. > > Sounds to me like there might still be an issue in gdb? Or at least > a difference in the way the type is calculated. > This on it’s own is still a good fix, so I’ll send a new version. I think we should learn the answer to the "where is that pointer coming from" question. I'm really not understanding why the shared library makes a difference. > > >> I wonder if what you're looking at is actually the malloc call? >> GDB will call malloc to allocate space for the "abc" string in >> the inferior. Look at the backtrace, see where the call is coming >> from. > > > With the nodebug and debug shared library version: > (I need to run to main before I can set breakpoint on cmp3, otherwise > "Function "cmp3" not defined.”) > > But with all versions, when stopped at cmp3, I get: > (gdb) bt > #0 0x00000000004005d4 in cmp3(char const*) () > #1 > #2 0x00000000004005a4 in foo() () > #3 0x00000000004005bc in main () That's a backtrace in the inferior. I meant instead for you to set a breakpoint on gdb's aarch64_push_dummy_call, figure out where the TYPE_CODE_PTR->TYPE_CODE_INT pointer comes from. With "b foo if (int)cmp3("abc") == 1", gdb will do two infcalls, one malloc call to allocate space for "abc" string, and then the call to cmp3. Thanks, Pedro Alves > >> >> Actually, because of that, I think it would be better (more focused) >> to pass in a variable instead of "abc". You already have the >> unused variable "word" there: >> >> const char *word = "stuff"; >> >> So: >> >> (gdb) b foo if (int)cmp3(word) == 1 >> >> but please rename it to something else, because I tried that >> locally and there's another symbol called "word" >> in glibc's localeinfo.h, and gdb picks that one up. > > Will do. > Using this still causes the bug in HEAD, so that’s ok. > > >> >> Also, is there a reason for the test to be a C++ program? >> If there's none, it'd be better to make it a C program, again >> to expose it to more targets. > > > Switching to C causes the bug to vanish. > This is because C++ uses gnuv3_pass_by_reference(), and the > segfault happens inside there, whereas C uses > default_pass_by_reference(), which just returns 0. > > I’ll expand the test to cover both C and C++.