From: Simon Farre <simon.farre.cx@gmail.com>
To: Tom Tromey <tromey@adacore.com>, Matt Rice <ratmice@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers
Date: Thu, 20 Jul 2023 11:47:02 +0200 [thread overview]
Message-ID: <12575ce2-bbeb-f73a-2a54-471d5a25e6a0@gmail.com> (raw)
In-Reply-To: <877cqxm4rl.fsf@tromey.com>
> 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
next prev parent reply other threads:[~2023-07-20 9:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-25 9:21 Simon Farre
2023-06-25 10:22 ` Eli Zaretskii
2023-07-13 20:38 ` Tom Tromey
2023-07-17 20:52 ` Simon Farre
2023-07-19 14:41 ` Tom Tromey
2023-07-17 21:53 ` Matt Rice
2023-07-18 18:52 ` Tom Tromey
2023-07-20 9:47 ` Simon Farre [this message]
2023-07-21 0:27 ` Matt Rice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12575ce2-bbeb-f73a-2a54-471d5a25e6a0@gmail.com \
--to=simon.farre.cx@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=ratmice@gmail.com \
--cc=tromey@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).