proposal: Add frame, value decorators
When I worked on GDB I came to feel that GDB was made so that GDB developers could debug GDB. This was how it was for a long time. But when we added with the Python API to GDB, along with Pretty Printing, frame decorators and filters, we handed back data representation to the user. Don't like how we print this object? Well, here's an API, and the ability to write your own, and hooks back into the display component to write your own representation. What parts of an object or value are important to the developer? It's going to depend on what that developer is trying to solve. So the default GDB information displays were, I think, more or less dependent on the feature implementor: usually what a GDB developer wanted to see when debugging their project (GDB).
So I know this is a super wishy washy proposal right now. But every value printed, every stack frame annotated, every backtrace printed, and so on, should first be offered to any extensions that want to work on them. That way a user can display any value they way they want to display it. If they don't care, well, they'll get the default version. Hopefully I've painted a rough picture of what I would love to see. Any more details, please ask! And if I can find some time, I hope to start putting some patches together.
I'm not the project's maintainer, so don't take my words as a commitment.
But the project has implemented certain features with extensibility in mind. For example, each frame/backtrace is processed with a frame formatter method. In the future this can be easily extracted for extensions to add a custom layer.
With that being said, the project is still at a very early stage (hasn't reached 1.0 yet!). So this may take a bit longer to happen.
To design the extensible API, we need to know
- what should we show
- how to show
From the technology side, there are several difficulties to support ractors and remote debugging. Maybe we can provide such APIs, but not super simple.