[wazari972]

this is not particularly hard to do with the Python interface: you define structures that are known by the process and the Python module + global variables, then you set an internal (silent) breakpoint on a given 'event' function. In the program you fill the structure with some queries, and in the Python breakpoint callback, you process it as you need. This is the way multi-thread debugging work (used to at least), shared library detection as well...

[kazinator]

Okay, good ideas there: so the program has some standard dispatch function that can be called to talk to the debugger. Normally that does nothing. The debugger can recognize this function and stick a breakpoint in it to alter the behavior.

The function can do something like put a request into a mailbox buffer, and then check for a reply in the inbox buffer. When there is no debugger, there is never any reply.

When the debugger stops the show with the breakpoint, it processes the request and prepares a reply, flipping some "reply present" flag; when the program is resumed then, it gets the reply.

It would be good not have any of that damned Python monkey business involved in this.

[wazari972]

> It would be good not have any of that damned Python monkey business involved in this.

please, GDB internals are open source, you can do all of that in plain C :D That's what I did initially, to give GDB the ability to distinguish user-level threads (see libthread_db).

Having a high-level language / interface to GDB is a great again of time !