From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1674704460; bh=Vr+vBpmoCX3xJZl8cqpUjjCpsGptXdvHwTtRPSeq6tc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OomEGZW5yvlKEGP9fOlfKK6ngqSMgcZWdl7ZB44OrQiJKCXTz/DmCLd7pFhNGI+3I h5OqiLpWPngLAFGWZqfHzDPd+Ye+O3FTqy2RUme1rTV9aCTwOUcFlji6AwSOqdwKRS SOPoLWL9SLSWrIzmqHLbPyGF9Yf2jzwNzNaQ1zMc= 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> From: Simon Marchi In-Reply-To: <875ycutgec.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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