From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UWXYAGH20WM+tyEAWB0awg (envelope-from ) for ; Wed, 25 Jan 2023 22:41:21 -0500 Received: by simark.ca (Postfix, from userid 112) id EA1C81E128; Wed, 25 Jan 2023 22:41:20 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Pk37x0AM; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A17D31E112 for ; Wed, 25 Jan 2023 22:41:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AFB463858C53 for ; Thu, 26 Jan 2023 03:41:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFB463858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674704479; bh=RER4TMXAo59SrQUBxVuKXPDGHBjHLw25myrLcYjbXC8=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Pk37x0AMOKb4XxLYBi8Msc8TAK3ZO6hGy34mlmo2PtLhc9aNQKADpO7cW8GJuDwLP m8d8CHsjqdX+raZnaEeYSoM94xrpn2+WV4CR9+cv18UQR5kE/4iDZ6fsTeenUS/Yz2 GQqpIDPcPZRBXXlmXxdSc31z+ZDwMoiYcchQS0DE= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 622573858D28 for ; Thu, 26 Jan 2023 03:41:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 622573858D28 Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B76341E112; Wed, 25 Jan 2023 22:40:59 -0500 (EST) Message-ID: <62a8ae16-1ebf-ebbb-fb0d-2c23cb56c5dc@simark.ca> Date: Wed, 25 Jan 2023 22:40:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 9/9] gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE Content-Language: en-US To: Tom Tromey , Simon Marchi via Gdb-patches Cc: Simon Marchi References: <20230106185729.42372-1-simon.marchi@efficios.com> <20230106185729.42372-10-simon.marchi@efficios.com> <875ycutgec.fsf@tromey.com> In-Reply-To: <875ycutgec.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 1/25/23 17:10, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches writes: > >>>>> {... {"memoryReference": "0x115d" > > Simon> The problem is that the PC to disassemble is taken from the breakpoint > Simon> insertion response, which happens before running. With a PIE > Simon> executable, that PC is unrelocated, but the disassembly request happens > Simon> after relocation. > > This is an odd one. It isn't super clear when memory references are > invalidated. (The spec doesn't even define what a memory reference is.) I'm not sure what you mean. The same could happen in a regular GDB test, if you grabbed a function's address, started the program, and tried to disassemble at that address. I don't expect GDB to be able to do anything with the unrelocated address obtained before running. Since there isn't a DAP event that says when symbols have changed (AFAIK), I think DAP clients have to assume that any symbol address may be invalid after resuming the program. > Simon> I chose to fix this by watching for a breakpoint changed event giving > Simon> the new breakpoint address, and recording the address from there. I > Simon> think this is an interesting way to fix it, because it adds a bit of > Simon> test coverage, I don't think these events are checked right now. > > This seems pretty good to me. > > Simon> - Do the disassembly by symbol instead of by address. > > I don't think this is possible in DAP. One of the many holes. When I saw this in the DisassembleArguments DAP structure: /** * Memory reference to the base location containing the instructions to * disassemble. */ memoryReference: string; I assumed that memoryReference could be pretty much anything that resolves to an address, essentially the same thing you could pass to GDB's disassemble command. But that's just my interpretation of it. Simon