From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id 4D37A3858D28 for ; Tue, 27 Jun 2023 12:41:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D37A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-4fb7b2e3dacso2627336e87.0 for ; Tue, 27 Jun 2023 05:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687869668; x=1690461668; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=Wd6EE91Mw+MyQNHtki2wV/sfltzzQ9s5kfznqYSw86s=; b=a4X5ypVIk4hc3h2tyTizJQjkwKntHN/Hl/DEYz9uy+I/lH+NFQgu70aDmpQR5s2IA/ oQzmmC1vYV00D5OdzDt9FCpMmXo2wCEUiRQ1PfJLaS1/rhNCAXtzSgnTlNrg9tQzHbnT OJ5NbxcF8F9TVnCgEeS0LozYNeyFk185r0z/55OfPMl3lVaP8sR6OXoKwUYRioRk71xO MtSKm4ZkvTojpEzD1/cLj5LMbIo7ew4LWoBXB5NSg/FvLZU66GJ7Rwe398SCUKB5Zmpc GDRVY1GkVTWKRJr+IcQkw46sp3o2rMyBe+L18HeMYN1UzgZuqXEbcu82lvaU0KheMr4r bu6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687869668; x=1690461668; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Wd6EE91Mw+MyQNHtki2wV/sfltzzQ9s5kfznqYSw86s=; b=RdclbA9t/AW75i07vEfwdXlpLCx8mp6PQYcB+JX16PRlM+1aEXkGO9FbiLPI9tY97c 0T3QX6nidOQWZ4UC8zAxwVDtRhyh2vnOb/UJdZOJoBYrjjWd+noruspUcwoQpnG4Zo4n qLSPaBVL/tIeDPJpc3NjkNvYtX1orrx8eJMAM6+PqD/WeI/cBkwic3fm9Q99CJoAgxEO KzrO5wss+poZ7t2rtvDQc7YEScAks3kAP6Eh7Pr4oGROBkDANJEsKxTj5nm7RMmqssrH fOhozlAfws9BDCuNFVnf5wRt+TM+xxDStc4lrG6Q8Q84JAqml0kJ64MGYbzQvpznAKzu 0RPA== X-Gm-Message-State: AC+VfDyC6YG7nCXcombevlVHF09QLjT/Kv9+QU5p4NkscW7/G5obtwZE O56i6+UmOqC3Ko+OsM4wVVw= X-Google-Smtp-Source: ACHHUZ6U1nwoOkW043gvLP868AvXcTQZv5gG44zTQCp3Wz0CktVffyTD81evNPg5yyDcdc9+bh0isA== X-Received: by 2002:a05:6512:ad6:b0:4f9:cb8f:3182 with SMTP id n22-20020a0565120ad600b004f9cb8f3182mr5523036lfu.25.1687869667284; Tue, 27 Jun 2023 05:41:07 -0700 (PDT) Received: from [192.168.1.20] (78-73-77-63-no2450.tbcn.telia.com. [78.73.77.63]) by smtp.gmail.com with ESMTPSA id b2-20020ac247e2000000b004fb881e5c23sm137437lfp.47.2023.06.27.05.41.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jun 2023 05:41:06 -0700 (PDT) Message-ID: Date: Tue, 27 Jun 2023 14:41:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v4] gdb/DAP Introduce new methods to to Pretty Printers To: Simon Farre References: <20230626153108.193139-1-simon.farre.cx@gmail.com> Content-Language: en-US Cc: gdb-patches@sourceware.org, Tom Tromey From: Simon Farre In-Reply-To: <20230626153108.193139-1-simon.farre.cx@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 just thought of something that I think we've both misunderstood about (well, at least I did) "Lifetime of Objects References" section in the DAP specification. To quote the section: "To simplify the management of object references in debug adapters, their lifetime is limited to the current suspended state. Once execution resumes, object references become invalid and DAP clients must not use them. When execution is paused again, object references no longer refer to the same objects. This means that a debug adapter can easily use sequentially assigned integers for different objects and reset the counter to 1 when execution resumes." This doesn't mean that *we* can't cache variables (or variable references) on the GDB side. Because *we* are not the client (in this scenario, we would be the "server", seeing as how the DAP is designed to be like a stateless protocol kind of like http) we can do whatever we want in our DAP-interpreter. It's only the *client* that can't rely on a variablesReference to mean the same thing between suspended states. This opens up for the possibility of, when building the stack metadata, such as locals, args, frames, perhaps the user visited older frames and retrieved the scopes etc - this could be cached until next suspension and if it's invalid at that point, throw it away, if not, serve it all up again. The question is, is the added complexity of caching variables (like I did for my DA) worth it, if the Pretty Printer API is smart enough and performant enough? Probably not, it's probably not likely at all that it's worth it. And by "smart enough" and "performant enough" I specifically mean a pretty printer API, where sub-regions, sub-ranges of variables can be fetched quickly, which this patch provides.