Re: GDB variants accepting plugins (to the debugger) ?

>>>>> "Matt" == Matt Rice <[email protected]> writes:

Matt> Anyhow I would be/have been somewhat interesting in putting in
Matt> time/effort into working on this sort of building out wasm inspired by
Matt> parts of the python API, but it feels like you'd probably want to put
Matt> a big experimental sticker on it in the sense that it could end up
Matt> with some component-model upstream change which in theory may mean
Matt> that the bytecode compiled pretty printer may be tied to a particular
Matt> version gdb using whatever version of the component model. In the same
Matt> sense that we currently rely on a python version (with the difference
Matt> being that python is much longer history of stabilization than the
Matt> component model which)

Matt> So in my opinion there is a little more to it than just putting in the
Matt> work, there is a lot less prior art than python modules.
Matt> Perhaps it would be best to start out with configure option not
Matt> enabled by default, with the understanding that it is currently
Matt> experimental.
Matt> something like --enable-experimental-wasm-plugins or some such.
Matt> Anyhow I would be excited to play around with it some if there was a
Matt> roadmap for how we want to handle these issues...

FWIW another idea in this space is the LLDB bytecode

https://lldb.llvm.org/resources/formatterbytecode.html

That page makes it sound like the plan is to have the compiler emit this
bytecode, but I haven't really paid attention to see if that's happened.

I wonder if it would be possible to implement any of these without
really touching the gdb core.  That is, some Python shims that load wasm
or whatever and do what is needed.

Tom