From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 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 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