From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 666613858C53 for ; Fri, 21 Jul 2023 00:28:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 666613858C53 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-qk1-x733.google.com with SMTP id af79cd13be357-765a4ff26cdso138721785a.0 for ; Thu, 20 Jul 2023 17:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689899284; x=1690504084; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1Y/VuuQHtPUhGU6gaxT3RL/SbcfJ5X3E0ca1n20Fb5k=; b=BdBkW1OmiLjq4O+tqPBHDb4deAB67fsn1Ax2A42UOdvYY+iKw/RZPk9FI9ykmDkFdp 9xrLoMYQl76hsMYrLSgWmO25Ho+ENajo0oUpkehBydJMDeqRKE8Ff60Eih124+Qubt1H s7FCkxns0CpZ4nTkDvxcMqv64JhY4itTKD8wU3NpyNG9GVNR2TdWzLaOCyAsMbH29Laj dkiMi3WP3ylvzVjOLmOyC2vJDuq19U18t6VYk+E6bjpnlvveSxMZtdG3adMpeeF5a+IP B7LjKxzbCGGsoX3/0CpL63IGPf4YgENP5YSFKGVfxLQdO1KIiRVfN11NjQPOusxMgAob CX/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689899284; x=1690504084; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1Y/VuuQHtPUhGU6gaxT3RL/SbcfJ5X3E0ca1n20Fb5k=; b=e+rus86VEta+kiPL/t1qvGn7kWG377lBlP/X0Tf0z7SUHHifeF1utiei0IWMapAN6e eNNgC2xSsLH3SHeHN6QvRkkzeFZIDCvkoYOoOx9+LM1TiqyUblFqwPH3sHu6mLBJDuSt LMtZVCAFJ8UQlvkJf8LTNDgEMfvlIpbXrtQn9gxgskNim4ssGjH0RzebBRKKLc608jO9 lyesj4xxSmIhsuFF9e+PYk3leVOOAqWPKOI7I+wON3Nsz1/x51EqxskVjeOVAzSvWu26 5dxipWLXRxUOe1YpMbGcA/XzGX6DTdfUYKr8Je7qmt0rFwPpsHnnntNB3d02PRWvrqRz +0IQ== X-Gm-Message-State: ABy/qLbjuHD7rr+W3M0Bct18b0gpfd8l7QWe6BZVXZ447RiK65Qd6nTt yPXbpXW45WFWdduivfcnc45Vj8CrDMbBU0qNWdE= X-Google-Smtp-Source: APBJJlGscYaFTjVRwt3O6dFqAFoOV+UbtPhp2v/pwTIsUsYBlq3+C7PAZW/7jQEM3XXPFp4/v8jWS3CDUmXaRyycbtY= X-Received: by 2002:a05:620a:17aa:b0:767:32bd:c2c3 with SMTP id ay42-20020a05620a17aa00b0076732bdc2c3mr311313qkb.47.1689899284172; Thu, 20 Jul 2023 17:28:04 -0700 (PDT) MIME-Version: 1.0 References: <20230625092116.252503-1-simon.farre.cx@gmail.com> <87jzv3o8ck.fsf@tromey.com> <877cqxm4rl.fsf@tromey.com> <12575ce2-bbeb-f73a-2a54-471d5a25e6a0@gmail.com> In-Reply-To: <12575ce2-bbeb-f73a-2a54-471d5a25e6a0@gmail.com> From: Matt Rice Date: Fri, 21 Jul 2023 00:27:52 +0000 Message-ID: Subject: Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers To: Simon Farre Cc: Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Thu, Jul 20, 2023 at 9:47=E2=80=AFAM Simon Farre wrote: > > > > Matt> FWIW, there has been a bit of spit-balling within the rust commun= ity > > 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 lang= uage, > > 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 selecte= d > > 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. Yeah the #[derive(Debug)] example was largely given as a pragmatic example, In that there is no current trait which matches an pretty-printer like API. Similarish traits would be Serialize/Deserialize, and https://crates.io/crates/cc-traits crate for collections, (not in std). But nothing really that enumerates only over the stuff you want to see. It seemed okayish to me primarily for a proof of concept, since it exists, is common and could reach a lot of developers without much burden. One thing your replies make me wonder about is the 'selecting pretty printe= rs', In the manual it specifies a search order in which these are controlled (falling back to 'raw-text' somewhat implicitly). I primarily use CLI, but in these debugger interfaces, would it be worthwhile considering giving pretty printers a 'sort'. So that we could register multiple pretty-printers 'formatted-text', 'array-like', 'struct-like', 'map-like'. This kind of selection mechanism with priority based on the sort of pretty-printer would perhaps work better for languages with trait/type-class like languages like rust and haskell. Since that tends to be how they implement enumeration. Part of what makes this difficult is the orphan rules, stating you either need to specify the trait, or the type implementing the trait. So unless the type provider or trait provider implements a `DebugWasm` trait it is hard to add it in a way the debugger could leverage. So adding/implementing enumeration-like mechanisms for pretty printing to these types of languages really has quite a few open questions. But in my mind `pretty-printer for objects that implement trait X where trait X is specified by the pretty printer`. whether it be `Debug`, `Collection where T: Debug`, or `Serialize= `, Additionally it would provide data for some form of a populated drop-down selection box, where users could select the pretty-printer That would seem to at least allow developers to leverage existing traits while not limiting things to formatted-text. However I could just be excessively complicating things here, but just spitballing ways that we can leverage existing things like formatted-text, while eventually being able to grow into a struct/array/map-like representation which I agree is desirable... Anyhow, this is probably beyond long enough. > Are there any lessons we can learn from LLDB here? How do they do it? *shrug*, I don't have any experience with 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