python-injected silent breakpoints broken since 1a853c52

python-injected silent breakpoints broken since 1a853c52

[Jan Kiszka]

Hi,

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

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: python-injected silent breakpoints broken since 1a853c52

[Joel Brobecker]

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

Re: python-injected silent breakpoints broken since 1a853c52

[Jan Kiszka]

On 2015-01-13 15:39, Joel Brobecker wrote:
> 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.

Done: https://sourceware.org/bugzilla/show_bug.cgi?id=17837

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux