From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by sourceware.org (Postfix) with ESMTPS id B4C173858D38 for ; Thu, 26 Jan 2023 15:09:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4C173858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from outbound-ss-761.bluehost.com (outbound-ss-761.bluehost.com [74.220.211.250]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 27997803317C for ; Thu, 26 Jan 2023 15:09:12 +0000 (UTC) Received: from cmgw15.mail.unifiedlayer.com (unknown [10.0.90.130]) by progateway8.mail.pro1.eigbox.com (Postfix) with ESMTP id 1478A10048189 for ; Thu, 26 Jan 2023 15:08:12 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id L3rHpeu9avm7ML3rHpG8Wr; Thu, 26 Jan 2023 15:08:12 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=T4lJ89GQ c=1 sm=1 tr=0 ts=63d2975c a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=QvcnE_ZH6cZqHNQPxQMA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iJD4EDdCWP5HKMkVuNJZZoM/lHDYKvZRqsBR8ze3oqc=; b=ePSM7bHctkr0qEOcNlWuCDOEK7 Jz7co5lALLUYhIFLmq/5lfuVPJJHlcnmQmMJg5yPs650YUQPCUUC49OfQAxet+r9u9EUQl//lQSvR IK4L26BmghRVyNjNiOJudW1oS; Received: from 75-166-146-144.hlrn.qwest.net ([75.166.146.144]:52620 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pL3rG-001LuE-Jk; Thu, 26 Jan 2023 08:08:11 -0700 From: Tom Tromey To: Simon Marchi via Gdb-patches Cc: Tom Tromey , Simon Marchi , Simon Marchi Subject: Re: [PATCH 9/9] gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE 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> X-Attribution: Tom Date: Thu, 26 Jan 2023 08:08:10 -0700 In-Reply-To: <62a8ae16-1ebf-ebbb-fb0d-2c23cb56c5dc@simark.ca> (Simon Marchi via Gdb-patches's message of "Wed, 25 Jan 2023 22:40:59 -0500") Message-ID: <87o7qls59h.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.146.144 X-Source-L: No X-Exim-ID: 1pL3rG-001LuE-Jk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-146-144.hlrn.qwest.net (murgatroyd) [75.166.146.144]:52620 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3020.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >> 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. 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. 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. Tom