Re: python-injected silent breakpoints broken since 1a853c52
Joel Brobecker <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Jan, > I've stumbled over a regression of gdb since commit 1a853c52 (make > "permanent breakpoints" per location and disableable). My gdb python > scripts [1] that load Linux kernel module symbols as the target loads > the modules now fail. > > The involved command is lx-symbols [2]. It installs a silent breakpoint > on a kernel function that is called when a module is loaded. Before > 1a853c52, the python callback was normally invoked and the target > continued to run. Since af48d08f (1a853c52 is not testable), the int3 > instruction (I'm testing with x86) is left in the target, and garbage > instructions are executed, causing a kernel oops. The breakpoint is > apparently not properly skipped (remove, single-step, re-insert) when > resuming the target on return from LoadModuleBreakpoint.stop(). > > I can provide more details on how to set up a reproduction case but I > would only gather them when desired as that is not straightforward. > > Jan > > [1] https://lkml.org/lkml/2014/11/20/531 > [2] > http://git.kiszka.org/?p=linux.git;a=blob;f=scripts/gdb/linux/symbols.py;h=bf05e451c58666add299061046bf1ceb9e82f4ef;hb=d92098e7cf60d31ccd025e56d20c23917ccd0819 Thanks for the report! Can you please open a PR at the following URL? https://sourceware.org/bugzilla/ There is a chance that we might consider this regression as release blocking for GDB 7.9 (planned for the near future), and having PR makes things a lot easier to track. Thank you! -- Joel