From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95828 invoked by alias); 29 Dec 2019 21:24: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 95733 invoked by uid 89); 29 Dec 2019 21:24:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=UD:m, HTo:D*ca X-HELO: EUR05-DB8-obe.outbound.protection.outlook.com Received: from mail-db8eur05olkn2100.outbound.protection.outlook.com (HELO EUR05-DB8-obe.outbound.protection.outlook.com) (40.92.89.100) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 21:24:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4Z0bKZI8CtvKO6DXyPfrMAMr1E85mnq6URyA6Luk5D/klaBf0xqZBDkMq098VYDrGvg3P/mWbuCaFyyB91uWiLOQZG3afpicH2uJy3CxPkiN8vYb0lxnLqpgSt7JKuqFmTW99f//mIh6lhgsfkrTUY7iSYiSZ04iL7IkrDSVVTzYGOYsPLkvpTP3aT3PmbeTpyKcgDryNCIA+ILq/jHGejsYQowyWIZIgoyqZ+QRFLP5yKQtgpnOyvL/bl7cfitznu8WwR2Z23BGtd+VIgCIMuqckBhvEQtKgjBc5gJKd3DXQ6SNKpW7gVW9BgZ5MTOUkwRSZBpXm9CZlCN7fjTUw== 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=XJ/u1vZgDT8qf2MBvkU+kTNNVPhOD5fy9D/G7KzVdhA=; b=IQTxxDVI3AOa+rC+wHPD2ZA7Kc8ZaKXXqwayKWaTT+CxhkazzJ0IXTTwMqM9mnQtYqMSj7URZTD1pTXAcvF4WjxrYRpPB1RxXAFu+hiR58TLMZ7h1rcPzZQLevkDlatSXcqzPbkJMgW4dotH6XUR8utjzoxvSJ7OprRuAujKw4wVFhT+fk86MTLl+VJlIMzDXB8nYSuNQzA6ZkrdphE/gMPQlPzOmmMVA8dk2HorA17gblKE35ZPxLne1Oxr3AwxqjERVFfIjZiQHnuM4jO3TmS3/1ee9FzZECLtR7TtLF+RisKxyId+XG1nMMzdXhi8vgMjj1qq8WpFjPkiuECNMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM6EUR05FT053.eop-eur05.prod.protection.outlook.com (10.233.240.59) by AM6EUR05HT095.eop-eur05.prod.protection.outlook.com (10.233.240.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Sun, 29 Dec 2019 21:24:09 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.233.240.52) by AM6EUR05FT053.mail.protection.outlook.com (10.233.240.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sun, 29 Dec 2019 21:24:09 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769%7]) with mapi id 15.20.2581.007; Sun, 29 Dec 2019 21:24:09 +0000 Received: from [192.168.1.101] (146.60.252.106) by FR2P281CA0009.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sun, 29 Dec 2019 21:24:08 +0000 From: Bernd Edlinger To: Simon Marchi , Andrew Burgess CC: "gdb-patches@sourceware.org" Subject: Re: [PATCHv2] Fix setting breakpoints or stepping on line 65535 Date: Sun, 29 Dec 2019 21:24:00 -0000 Message-ID: References: <20191201220818.GI3410@embecosm.com> <20191229203253.GP3865@embecosm.com> <5ea099d0-6fc4-c4b1-06b1-a0403f92eb7a@simark.ca> In-Reply-To: <5ea099d0-6fc4-c4b1-06b1-a0403f92eb7a@simark.ca> x-microsoft-original-message-id: <7311cbe3-f7b2-5309-8311-dec139dc1ac4@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg01065.txt.bz2 T24gMTIvMjkvMTkgOTo0MSBQTSwgU2ltb24gTWFyY2hpIHdyb3RlOg0KPiBP biAyMDE5LTEyLTI5IDM6MzIgcC5tLiwgQW5kcmV3IEJ1cmdlc3Mgd3JvdGU6 DQo+PiBJIHBsYWNlIG1vcmUgdmFsdWUgb24gaGF2aW5nIHRlc3RzIGFuZCBj aGFuZ2VzIGluIHRoZSBzYW1lIGNvbW1pdCAtIEkNCj4+IGZpbmQgaXQgbW9y ZSB1c2VmdWwgdGhlIG90aGVyIHdheSBhcm91bmQsIHdoZW4gSSBmaW5kIHNv bWUgY29kZSBJDQo+PiBkb24ndCB1bmRlcnN0YW5kIGFuZCBJIGZpZ3VyZSBv dXQgd2hpY2ggY29tbWl0IGl0IGNhbWUgZnJvbSwgaGF2aW5nDQo+PiB0aGUg dGVzdHMgaW4gdGhlIHNhbWUgY29tbWl0IG1lYW5zIGl0IGlzIGVhc3kgdG8g a25vdyAidGhpcyB0ZXN0Ig0KPj4gc2hvdWxkIGNoZWNrICJ0aGlzIGNvZGUi Lg0KPj4NCj4+IElmIHRoZSB0ZXN0IGFuZCBjaGFuZ2VzIGFyZSBzZXBhcmF0 ZSBJIGhhdmUgdG8gZG8gbW9yZSB3b3JrLiBCb28hDQo+Pg0KPj4gRm9yIHRo aXMgcmVhc29uLCBpZiB5b3UndmUgbm90IGFscmVhZHkgcHVzaGVkIHRoaXMg cGF0Y2gsIGNvdWxkIHlvdQ0KPj4gY29sbGFwc2UgdGhlIHRlc3QgYW5kIGNo YW5nZSBpbnRvIGEgc2luZ2xlIGNvbW1pdCBwbGVhc2UgYmVmb3JlDQo+PiBw dXNoaW5nLg0KPiANCj4gRldJVywgdGhhdCdzIG15IHByZWZlcmVuY2UgdG9v Lg0KPiANCg0KT2theSwgd2lsbCBkby4NCg0KVGhhbmtzIQ0K >From gdb-patches-return-162658-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Dec 30 15:38:20 2019 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 27796 invoked by alias); 30 Dec 2019 15:38:20 -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 27746 invoked by uid 89); 30 Dec 2019 15:38:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL,BAYES_00,NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:server2, H*RU:sk:server2, HX-Spam-Relays-External:sk:server2, I'd X-HELO: mail.bob131.so Received: from server2.bob131.so (HELO mail.bob131.so) (128.199.153.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Dec 2019 15:38:18 +0000 Received: from internal.mail.bob131.so (localhost [127.0.0.1]) by mail.bob131.so (Postfix) with ESMTP id 5F3A552C24; Mon, 30 Dec 2019 15:38:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bob131.so 5F3A552C24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bob131.so; s=default; t=1577720295; bh=3IrPNN4mxma71bQ2jtYSfwzLAEyaUpuubw5iSl4lO5c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cdsyMBqwEVd4bq5VPz5hucaRCK07p/YSoqu0L9DCpWRJK/6PK/tscBTTldlVxtwlx FeXYC0bFS0SpIOzz7fF5GJJvX10oduMNAO4DAne08SqLWhjxbfI3+K4jU0XhzuYdVv KEWZU2q0h8NxljZ8Xz0A9nQ46CN93xyeHb0rUgylB5xzocJa4WZDyYsbYGdRN5assC l4psZEWTh0JUtn1gQeEEbcatsHXtPWDSFgRhZA54tE65B5tCbDlVJFd4RsK5HDNc0P a+G1ew38IcXp+dgxId2mwrLVtza9i+KuYkMf8ZjnoqhR9WxFyxiGilQPgzDHbUEda+ Vw4Mvv3Q4aF4w== Date: Mon, 30 Dec 2019 15:38:00 -0000 From: George Barrett To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix handling of null stap semaphores Message-ID: <63-043i577lrr0nz3p9q-864io50kubhf/q6&oul1hzd/xh4.u6c@mail.bob131.so> References: <5we87igzwt5_kr.5b-38floyexzwmozuj6vb-.hmx8r4u3r41_sy@mail.bob131.so> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SW-Source: 2019-12/txt/msg01066.txt.bz2 Content-length: 2528 On Sun, Dec 29, 2019 at 01:58:46PM -0500, Simon Marchi wrote: > Though the ChangeLog should mention the modified functions, I propose to use > this: > > * stap-probe.c (stap_modify_semaphore): Don't check for null > semaphores. > (stap_probe::set_semaphore, stap_probe::clear_semaphore): Check > for null semaphores. Ack. > I'd really like if we could have a test for this, so that eventual refactors > don't re-introduce this bug. Perhaps the gdb.base/stap-probe.exp test could > be enhanced to test that the ELF magic number hasn't been changed? I was secretly hoping no-one would notice the absence of a test case ;) > One difficulty is finding out where it is, I don't know if there's a GDB > command that will compute that directly. One way is to take the address of > a global variable before and after starting the process, and see how it has > been relocated, that would be the base of the image: > > (gdb) p &some_global > $1 = (int *) 0x402c > (gdb) start > Temporary breakpoint 1 at 0x111d: file test.c, line 9. > Starting program: /home/simark/src/aoc/08/p2/a.out > > Temporary breakpoint 1, main () at test.c:9 > 9 for (i = 0; i < 1000; i++) { > (gdb) p &some_global > $2 = (int *) 0x55555555802c > (gdb) p/x 0x55555555802c - 0x402c > $3 = 0x555555554000 > (gdb) p (*(char*) 0x555555554000)@4 > $4 = "\177ELF" Is it too glibc-specific to use _r_debug? Something like the following: (gdb) start Temporary breakpoint 1 at 0x4e60: file ../src/ls.c, line 1451. Starting program: /usr/bin/ls Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd8d8) at ../src/ls.c:1451 (gdb) p/x _r_debug.r_map->l_addr $1 = 0x555555554000 (gdb) p (*(char*) _r_debug.r_map->l_addr)@4 $2 = "\177ELF" > Also, the semaphore is set when the breakpoint is inserted and cleared when > the breakpoint is removed. By default, GDB removes the breakpoints while > the inferior is stopped, so if we inspect the magic number while the > inferior is stopped, it will appear OK. > > However, we can use "set breakpoints always-inserted on" to make GDB leave > the breakpoint inserted when the inferior is stopped. Thanks for the tip, that seems like something that could have been pretty frustrating to find out on my own. > I think all this only applies if the main program is a position-independent > executable, so this test should probably be skipped if we detect the > relocation is 0. Ack. > So with all this it should be pretty straightforward to improve the test to > check for this. Thanks