2 ms·
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, the
by wazari972 9y ago
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 9y agoOkay, 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 9y ago> 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 !