Re: Breakpoint meeting

[Andrew Cagney <cagney at redhat dot com>]

First thanks to Nurden for making these notes.

Wu Zhou wrote:
> Quoting Nurdin Premji <npremji@redhat.com>:
>
>
>> Second method involves kprobes.
>>
>> When we insert the breakpoint, we know the instruction it is replacing.
>> So we copy the entire instruction, put it somewhere else* in the running
>> process
>> Set the thread pc to point to this copy,
>> single step execute,
>> put pc back to where it should be after the instruction,
>> and continue.
>
> Do you mean you will use kprobe to replace the instruction at the
> breakpoint address? As far as I know, kprobe is used in kernel space.
> Maybe you meand something similar in kprobe in user space. I know that
> there are some user-space probe proposal there, but I am not sure if
> they are mature enough for our usage.
>
> If you could elaborate a little on this method, that will be highly
> appreciated.
No, the intent is to borrow the underlying technique used by kprobes,
not actually use kprobes :-) However, long term if the kernel were to
grow a better low-level mechanism we'd be all over it!

>
>> Also we have to ignore system calls because we can't do system call
>> tracing and single stepping at the same time. This is apparently a
>> kernel bug.
>
> I guess the utrace mechanism Roland McGrath proposed can resolve this.
> If it is, maybe we can re-conisder this, at least at desigh phase. My
> two cents anyway.
The above is an implementation, rather than design, decision. We can
investigate the possability of working around the bug later (like we did
for the bug where ptrace only works from one thread). Yes, we're
expecting utrace to address this sort of problem.

Andrew