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 500663858CDB for ; Thu, 20 Jul 2023 09:47:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 500663858CDB 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-4f954d7309fso823678e87.1 for ; Thu, 20 Jul 2023 02:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689846425; x=1690451225; h=content-transfer-encoding:in-reply-to:cc:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KIDM/L8SxJ5AbJ06AIYGhjRDa11ZfhH9GZEpdVJcIIM=; b=eoqx1A6W96rThngtt3rqNmxuX/MkS4CQvKbbAhQRvm6GP0Tqp+M6vmmcJbup7z1pcf GC9FPhv98ZSy9ooH/EEu9qWLPvn5QduAHTYxjvHmV+BKIfQCtQpWm+Nhx+09ucBGuvFv zzfSCLV4enwtk7LctZmg1H6FV/MZ9UosA2OoamZYriH1rTlwrvjg6u//KPnF8mcdlv+H sAxTlpEECyX+8YKTp+MB/HyhNsK2SnXBdS0LedY8k1xmsjha9U9I/p4ofFErZ7iBXrDR CSVxT09leF53trMNg6Ro+DNpb797KPWRw1zLrMxIWVWkfqsjQZ3b4Av16HKX7+VAOnjx QhUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689846425; x=1690451225; h=content-transfer-encoding:in-reply-to:cc:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KIDM/L8SxJ5AbJ06AIYGhjRDa11ZfhH9GZEpdVJcIIM=; b=FFlGGIjPaIOuEKklhdIQucWBm55ghrroKdQuFgA4bFMool1Ftl+unLNM6zcmsQGijc nLe+XGgoAZymGm3hBe9cPAvNt20i4O5bo5jyN7eHCmfDZRFQY/pvMVj70N4vmA5U0aRN XRq9gCQVkqmaeGZBP9Mu+L+r5jX6uuLNYoH2IQQTaZco1eJ6KBGft+u3DfSQi9txXCkF O2aZyTtz9Mil+9NR+g4QfkithamzuMkc/xNQgeH9P+rv0zgMYZ9crqcxHpzy73XykMTu xBbJRenfPDfcIOCgbeh6wc4bXdB/XFAHkpDArim2/FDaiChYjegzf4qN4uurH3eN5Ir1 1O9A== X-Gm-Message-State: ABy/qLbysd+yISayWMgIt51v2CGRNCw1Ax+X2HD9y4QJvJD2UkctUgcM Q47h3W2WW/V8D91zyu9b+/hJr6KqYfg= X-Google-Smtp-Source: APBJJlFUSTC8wmz1zqxneeIOZEdwhfHHbO4kfUl2BXR+EQ4117undVb106I+mhiBgrSRDcOnGKXqzQ== X-Received: by 2002:a05:6512:3a83:b0:4fb:c9e1:5286 with SMTP id q3-20020a0565123a8300b004fbc9e15286mr1024736lfu.7.1689846424287; Thu, 20 Jul 2023 02:47:04 -0700 (PDT) Received: from ?IPV6:2001:2044:c7:5500:5637:6b43:7745:198c? ([2001:2044:c7:5500:5637:6b43:7745:198c]) by smtp.gmail.com with ESMTPSA id y9-20020a197509000000b004fba785d549sm115958lfe.263.2023.07.20.02.47.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jul 2023 02:47:03 -0700 (PDT) Message-ID: <12575ce2-bbeb-f73a-2a54-471d5a25e6a0@gmail.com> Date: Thu, 20 Jul 2023 11:47:02 +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 v1] gdb/DAP Introduce new methods to to Pretty Printers Content-Language: en-US To: Tom Tromey , Matt Rice References: <20230625092116.252503-1-simon.farre.cx@gmail.com> <87jzv3o8ck.fsf@tromey.com> <877cqxm4rl.fsf@tromey.com> From: Simon Farre Cc: gdb-patches@sourceware.org In-Reply-To: <877cqxm4rl.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 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: > Matt> FWIW, there has been a bit of spit-balling within the rust community > Matt> about leveraging Debug trait implementations > Matt> within pretty printers, where what seemed to me like the obvious way > Matt> to leverage these was to compile Debug impls to wasm, > Matt> and write a python wrapper which calls into the wasm. I haven't > Matt> thought or looked into it too much to have considered any hurdles of > Matt> this approach really, but it would be nice if languages with wasm > Matt> toolchains could define/compile pretty printers in their own language, > Matt> since often they already exist for the purpose of runtime logging... > Matt> Seemed worth bringing up if we're spit-balling here too. > > Ages ago I looked into this a little, the idea being to compile selected > functions to Python using the gdb API. In the end though it seemed too > hard for the value it would deliver. > > Anyway, the wasm approach seems fine -- they solved all the toolchain > problems, which is nice. The main issue is that, IIUC, debug traits > just emit a string representation -- but IMO the debugger really wants a > more key-value / array-like representation. > > This seems like something that could be implemented "on the side", like > the way that gdb-natvis exists. > > Tom Right, I would agree with Tom here. Having it just represented as a string is sort of the "problem" we're in and even though a lot of people  (maybe even a majority) still use CLI/TUI, I'm not particularly sure demanding new users going forward should be forced to accept such a user interface, instead of having it as a choice. A GUI and a CLI/TUI have to make substantially different design choices, because a CLI is always a REPL, so each individual operation can be somewhat costly, because it's going to feel sort of fast for the end user anyway, whereas a GUI can see large swathes of the program at every instant - making each and every one of those operations build up to a total cost pretty quickly. So, being able to query the types "directly", which means, sub objects, ranges etc is something that's valuable. GDB-CLI provides something like this with simple C-like types (the foo@10 expression). So, I think that excludes the #[derive(DebugWasm)] (ish) approach, unless it fulfills the requirements I've talked about here. I do like the idea that it would mean not having to write pp's for everything though. Are there any lessons we can learn from LLDB here? How do they do it? Then again, what's good about GDB/Python (and therefore the DAP interp) is that it allows for some customizability by the DA, so for instance, I would drive my DA to enforce the num_children/children_range approach, since the point of my DA was performance. So I think, no matter where we land, it's probably good if we could let the DA-implementer have room to make the tradeoffs it desires. It's also why I think it'd be good if the DAP interpreter isn't too reliant on MI because I believe MI was meant to solve a different problem (remote, vs a unified GUI & remote-protocol). Simon