Question about Python API actions on breakpoint hits
Matheus Branco Borella via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Hey there, all. I have been, as of recently, writing some features for a GDB plug-in written in Python called pwndbg. And during that, twice I've come across this one limitation regarding changing the state of the inferior from within the `gdb.Breakpoint.stop()` function, which includes changing breakpoints. I've got a few questions regarding this limitation. Firstly, both the features where I've run up against it deal with dynamic analysis, where both the events being analyzed and the events that signal changes in the set of analysis targets can only be observed through BPs/WPs. A concrete example of this in the wild[1] is how, if (1) you're counting calls made across shared library boundaries using BPs and (2) your source for changes in the current set of loaded libraries is a BP on `r_brk`, properly reacting to those changes necessitates removing and installing BPs from inside `.stop()`. Of course, another option would be to stop the program and perform these changes during a stop event handler. But that means either running the risk of stopping the program when the user is not expecting it to, or, if that handler `continue`s the program, not stopping the program when the user is expecting it to - eg. in the case of `next` or `stepi`. I've read the documentation, and indeed, doing these changes during `.stop()` is not a supported use case[2]. And additionally, to the best of my knowledge, there does not seem to be a supported way to, in reaction to a breakpoint, change the state of the inferior, that doesn't also have the issues I outlined above. My question is, why is that? Is there anything major blocking proper support for such a feature being implemented? And if so, what is it? This is useful enough that, at least the "create a gdb.FinishBreakpoint from inside the `.stop()` function" version of this mechanism appears twice in the wild[3][4]. And, in particular, gdb.FinishBreakpoint seems to, in my experience, miss ocasionally when set from inside `.stop()`, when calling the `finish` command from the same code location works fine. [1]: https://github.com/pwndbg/pwndbg/pull/1971 [2]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Breakpoints-In-Python.html [3]: https://github.com/hugsy/gef/blob/b56bf9dc48220aeab345722378e87abd9912c5a5/gef.py#L4200 [4]: https://github.com/pwndbg/pwndbg/pull/1841