public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Question about Python API actions on breakpoint hits
@ 2024-01-12  0:32 Matheus Branco Borella
  2024-01-25 17:08 ` Tom Tromey
  0 siblings, 1 reply; 2+ messages in thread
From: Matheus Branco Borella @ 2024-01-12  0:32 UTC (permalink / raw)
  To: gdb; +Cc: Matheus Branco Borella

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question about Python API actions on breakpoint hits
  2024-01-12  0:32 Question about Python API actions on breakpoint hits Matheus Branco Borella
@ 2024-01-25 17:08 ` Tom Tromey
  0 siblings, 0 replies; 2+ messages in thread
From: Tom Tromey @ 2024-01-25 17:08 UTC (permalink / raw)
  To: Matheus Branco Borella via Gdb; +Cc: Matheus Branco Borella

>>>>> "Matheus" == Matheus Branco Borella via Gdb <gdb@sourceware.org> writes:

Matheus> Hey there, all. I have been, as of recently, writing some features for a GDB
Matheus> plug-in written in Python called pwndbg. And during that, twice I've come across
Matheus> this one limitation regarding changing the state of the inferior from within the
Matheus> `gdb.Breakpoint.stop()` function, which includes changing breakpoints. I've got
Matheus> a few questions regarding this limitation.
[...]
Matheus> I've read the documentation, and indeed, doing these changes during `.stop()`
Matheus> is not a supported use case[2]. And additionally, to the best of my knowledge,
Matheus> there does not seem to be a supported way to, in reaction to a breakpoint,
Matheus> change the state of the inferior, that doesn't also have the issues I outlined
Matheus> above.

Matheus> My question is, why is that? Is there anything major blocking proper support for
Matheus> such a feature being implemented? And if so, what is it?

TBH I am not sure.  Maybe nobody really knows -- probably the only
answer is to try it and then debug gdb and figure out what is going
wrong.

Tom

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-01-25 17:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-12  0:32 Question about Python API actions on breakpoint hits Matheus Branco Borella
2024-01-25 17:08 ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).