From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KkvrKdng0mM/SiIAWB0awg (envelope-from ) for ; Thu, 26 Jan 2023 15:21:45 -0500 Received: by simark.ca (Postfix, from userid 112) id 9EE8A1E128; Thu, 26 Jan 2023 15:21:45 -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=Rgh/BLa8; 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 3D9A11E110 for ; Thu, 26 Jan 2023 15:21:45 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 93F3C3858C83 for ; Thu, 26 Jan 2023 20:21:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93F3C3858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674764503; bh=k9zjl06dBndcb7pI2TZHBZn0Q96fuy8INPjdiHZwNVw=; 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=Rgh/BLa8JWq/sO/s0n5myZRgH/SLCU2vpjoMRSGwRU3i0vbGz+0oSXxE/crnSW0Kj 2iqdovhyb1scbxmNv8SeH02kYiuhRNO4DKrqQ2S4Iz55uqOlWVPflrvTKrfc854Z2C a485OqgXzLXP4MqyKJpCtdL70kH2obcngp0P8hhM= 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 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) 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 In-Reply-To: <87o7qls59h.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/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