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 AD3E73858D28 for ; Thu, 26 Jan 2023 20:21:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD3E73858D28 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 [172.16.0.192] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B91371E110; Thu, 26 Jan 2023 15:21:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1674764479; bh=DOK17FE0+q8UGIECgyVjxBfgAX31Z7r5J0Up778xd6k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=uA9SpObMDtLpzpyr85dns6jhWcShW5ELw4tRD+RJn75yyfwmfX9FAz2kwziE58R6v Z06pjkhCOJD9q9eb4a3u5Hqn3Mh3Pa5BDZg+7ZyOByJ4vPbWLAT7mG3KscaKrkqJoP dFphZFaVVPOW8JcgLsEbHyIROgLBr1XNe28Nj5nk= Message-ID: Date: Thu, 26 Jan 2023 15:21:17 -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 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> <62a8ae16-1ebf-ebbb-fb0d-2c23cb56c5dc@simark.ca> <87o7qls59h.fsf@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87o7qls59h.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/26/23 10:08, Tom Tromey wrote: >>> 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.) > > Simon> I'm not sure what you mean. > > Actually I used the wrong word there. In this case the term is really > "instruction reference" > > Anyway, what I mean is that the DAP spec refers to "instruction > reference" without defining it. So for example the response to a > setBreakpoints request is essentially an array of Breakpoint, which is > documented as: > > /** > * A memory reference to where the breakpoint is set. > */ > instructionReference?: string; > > However, what are the semantics of this? The spec does not say. So, we > don't know what values might be valid (and pragmatically I think a > client has to assume it must treat them as opaque cookies). When are > they invalidated, or are they assumed to be valid for the lifetime of > the inferior? > > Maybe gdb could send an InvalidatedEvent but even this is pretty vague. Ok, thanks for the explanation. Well, the client gets an initial instructionReference for the breakpoint. But then GDB sends a "breakpoint changed" event for that same breakpoint, with a new instructionReference. That sounds like a good way to tell the client "your old instructionReference for that breakpoint is not longer valid". > > Simon> Since there isn't a DAP event that says when symbols have changed > Simon> (AFAIK), I think DAP clients have to assume that any symbol address may > Simon> be invalid after resuming the program. > > I agree, though it's unwritten. > >>> I don't think this is possible in DAP. One of the many holes. > > Simon> When I saw this in the DisassembleArguments DAP structure: > > Simon> /** > Simon> * Memory reference to the base location containing the instructions to > Simon> * disassemble. > Simon> */ > Simon> memoryReference: string; > > Simon> I assumed that memoryReference could be pretty much anything that > Simon> resolves to an address, essentially the same thing you could pass to > Simon> GDB's disassemble command. But that's just my interpretation of it. > > This would be convenient and perhaps it is what gdb ought to do, but I > don't see any text in the spec supporting this approach, so unless a > client specifically knows it will only talk to gdb, it seems risky for > them to use it. And of course if you're specifically talking only to > gdb, you might as well use MI, which despite its flaws has solved all > the problems that DAP still has. > > Probably what would be better for gdb is something that uses the DAP > transport -- JSON-RPC is just amazingly easy to work with -- but with MI > requests as the high-level protocol. Or, that would have been better in > some alternate universe anyway. I would support changing MI to use JSON-RPC or similar. At least, if the output could be JSON, rather than the current output that kinda looks like JSON but isn't, it would be nice. But even command input would benefit from having a better structure. I don't recall them at the moment (because I haven't worked on a frontend for a long time), but there are some inconsistencies between commands, how things should be quoted, escaped, etc. > Anyway I imagine the route forward is to file a bunch of DAP bugs and > try to get them resolved; though I haven't seen much progress on, e.g., > the multiple location bug. It will happen when somebody at Microsoft needs it, I suppose. Simon