From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id ADEC43858D37 for ; Thu, 27 Jul 2023 19:42:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADEC43858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-348d333e441so5502485ab.2 for ; Thu, 27 Jul 2023 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1690486921; x=1691091721; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=cCLkbwug5H0tHOat2PQ3z+HYP+djxf9vZexqBjNrAHM=; b=kXI3KKJs4VILI8SOIftp/qKLdUfKoSwg538mEtSVMyAoFiScneLm1PWzqqpIaF6nkX uKqF2+wshO9xQFrH69BsuIgwKcGwGKPjtCVyLEsVfFaxRm7+YsYQqM3/zRXPfW30TqVN VpBcBWoYn4oKqFvwumd1rVkY48rT7mS1GdYtRTVBRTLU0w5RqlYVxwgLNPmuLEDKShp0 5pHH2Kx7Wk0SL94RLOM8eWwusD+kzwTgQsjND0k6QgLoaDjn1xSO/fAwTFwUmXChJaxp FC2TMrD7si3/bBWRppe2dIWKr2Z90o0SmxgnBeqTdVuTvsCLmvNp5faHNaqsSUvpM88H gr0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690486921; x=1691091721; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cCLkbwug5H0tHOat2PQ3z+HYP+djxf9vZexqBjNrAHM=; b=H2GeCPQf4pz7zF5RWJvfqJCJusjJiBYWKCimkCWM6CRRg/qnKuZ1f1Rx0J1dhZvYep wreObj0gsfMIe5MHZNW4whIW63uFyyyLIbDlzoBsS1JQTg+UgiMwZvLxhlBlhrPyStB9 WDvoyTNUkge4JecSjsJFgT0qQwmWa8vZzqNNrJnhN5VtybQdFEfFiMXbAjgPvic0W8Qm ffW23B3XlmOmGwpLAWTU2wF61J0lwVO6AswTnX3AjR/FHE6U88wy+0lblzWvjZKJMjYj 1oVxeaKd3TI/jZfBMS1y2zoCIX9hJrBh4/b0SNewOOk4hhonpHN/xROQ3m18D/xFy1nY kA5Q== X-Gm-Message-State: ABy/qLaDBaS+smEfY1wnLT1L/MD9+DWCkmAyPVfEzxlUAcGvCOvX/Q5z t05rov93Mj/2o4baP7EukK9yg2BEhXlx8NukTO5/1g== X-Google-Smtp-Source: APBJJlG1ODPqUneTwu6mHECDyQvLZ05QONTpnxULi8UkAj6D28vPCLZIuKky5Cu1OpOaaY1khcbu5Q== X-Received: by 2002:a05:6e02:174e:b0:348:d89b:268 with SMTP id y14-20020a056e02174e00b00348d89b0268mr490751ill.7.1690486920841; Thu, 27 Jul 2023 12:42:00 -0700 (PDT) Received: from localhost.localdomain (75-166-135-140.hlrn.qwest.net. [75.166.135.140]) by smtp.gmail.com with ESMTPSA id gs14-20020a0566382d8e00b0042b61a5087csm593680jab.132.2023.07.27.12.41.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jul 2023 12:42:00 -0700 (PDT) From: Tom Tromey To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH] Respect supportsMemoryReferences in DAP Date: Thu, 27 Jul 2023 13:41:50 -0600 Message-Id: <20230727194150.2475942-1-tromey@adacore.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: I noticed that the support for memoryReference in the "variables" output is gated on the client "supportsMemoryReferences" capability. This patch implements this and makes some other changes to the DAP memory reference code: * A small refactoring to VariableReference to avoid "del". * Don't use the address of a variable as its memoryReference -- only emit this for pointer types. There's no spec support for the previous approach. * Use strip_typedefs to handle typedefs of pointers. Note that this code still ignores the constraint that a memoryReference for a "variables" response that says that this should only be used for pointer-to-function. "evaluate" does not have this constraint and so it seemed needless to me. I filed a DAP bug report about this: https://github.com/microsoft/debug-adapter-protocol/issues/414 --- gdb/python/lib/gdb/dap/evaluate.py | 7 ++----- gdb/python/lib/gdb/dap/varref.py | 23 +++++++++++++++++++---- gdb/testsuite/gdb.dap/memory.c | 2 ++ gdb/testsuite/gdb.dap/memory.exp | 2 ++ gdb/testsuite/lib/dap-support.exp | 3 ++- 5 files changed, 27 insertions(+), 10 deletions(-) diff --git a/gdb/python/lib/gdb/dap/evaluate.py b/gdb/python/lib/gdb/dap/evaluate.py index 63e80331b24..ae8cacc3e0f 100644 --- a/gdb/python/lib/gdb/dap/evaluate.py +++ b/gdb/python/lib/gdb/dap/evaluate.py @@ -55,12 +55,9 @@ class _SetResult(VariableReference): def __init__(self, value): super().__init__(None, value, "value") - def to_object(self): - result = super().to_object() + def add_memory_reference(self, result, addr): # This is not specified in the setExpression result. - if "memoryReference" in result: - del result["memoryReference"] - return result + pass # Helper function to perform an assignment. diff --git a/gdb/python/lib/gdb/dap/varref.py b/gdb/python/lib/gdb/dap/varref.py index 213151fd3d3..4537fbacf8b 100644 --- a/gdb/python/lib/gdb/dap/varref.py +++ b/gdb/python/lib/gdb/dap/varref.py @@ -150,6 +150,14 @@ class VariableReference(BaseReference): self.count = num_children return self.count + def add_memory_reference(self, result, addr): + """Add a memoryReference to the RESULT dictionary. + + ADDR is the address of the memory. + The caller ensures that the client capability is set. + This may be overridden by subclasses.""" + result["memoryReference"] = hex(int(addr)) + def to_object(self): result = super().to_object() result[self.result_name] = self.printer.to_string() @@ -162,10 +170,17 @@ class VariableReference(BaseReference): result["indexedVariables"] = num_children else: result["namedVariables"] = num_children - if self.value.type.code == gdb.TYPE_CODE_PTR: - result["memoryReference"] = hex(int(self.value)) - elif self.value.address is not None: - result["memoryReference"] = hex(int(self.value.address)) + if client_bool_capability("supportsMemoryReferences"): + # "evaluate" allows a memory reference for any pointer + # type, while "variables" seems to only allow it for + # pointer-to-function or pointer-to-method. However, the + # restriction seems strange. This is filed as: + # https://github.com/microsoft/debug-adapter-protocol/issues/414 + # Meanwhile, allow pointers. The same issue brings up the + # idea of using the variable's address here, but for the + # time being we don't. + if self.value.type.strip_typedefs().code == gdb.TYPE_CODE_PTR: + self.add_memory_reference(result, self.value) if client_bool_capability("supportsVariableType"): result["type"] = str(self.value.type) return result diff --git a/gdb/testsuite/gdb.dap/memory.c b/gdb/testsuite/gdb.dap/memory.c index 3b9f6138abe..630e23dcf01 100644 --- a/gdb/testsuite/gdb.dap/memory.c +++ b/gdb/testsuite/gdb.dap/memory.c @@ -19,6 +19,8 @@ uint32_t thirty_two = 7; +uint32_t *thirty_two_p = &thirty_two; + int main () { return 0; /* BREAK */ diff --git a/gdb/testsuite/gdb.dap/memory.exp b/gdb/testsuite/gdb.dap/memory.exp index ab0516d6b3d..d702d5b5dee 100644 --- a/gdb/testsuite/gdb.dap/memory.exp +++ b/gdb/testsuite/gdb.dap/memory.exp @@ -47,6 +47,8 @@ set obj [dap_check_request_and_response "evaluate global" \ evaluate {o expression [s thirty_two]}] dap_match_values "global value" [lindex $obj 0] "body result" 7 +set obj [dap_check_request_and_response "evaluate global pointer" \ + evaluate {o expression [s thirty_two_p]}] set addr [dict get [lindex $obj 0] body memoryReference] set obj [dap_check_request_and_response "read memory" \ diff --git a/gdb/testsuite/lib/dap-support.exp b/gdb/testsuite/lib/dap-support.exp index e3750e1d016..4183526a320 100644 --- a/gdb/testsuite/lib/dap-support.exp +++ b/gdb/testsuite/lib/dap-support.exp @@ -233,7 +233,8 @@ proc _dap_initialize {name} { return [dap_check_request_and_response $name initialize \ {o clientID [s "gdb testsuite"] \ supportsVariableType [l true] \ - supportsVariablePaging [l true]}] + supportsVariablePaging [l true] \ + supportsMemoryReferences [l true]}] } # Start gdb, send a DAP initialize request, and then a launch request -- 2.40.1