This is the mail archive of the
mailing list for the Archer project.
Re: hw_breakpoint userland interface
On 02/10, Roland McGrath wrote:
> > Do you have any plans to introduce something like per-process
> > breakpoints, or (apart from inheriting) everything continues to
> > be per-thread?
> I think we should look at doing what makes most sense for the users,
> i.e. GDB. It's my impression that what is really desired is both options.
> In fact, I'm not altogether sure that anyone wants per-thread watchpoints
> at all, that being data watchpoints. When the issue is finding how some
> memory gets touched, then it doesn't make much sense to confine it to a
> particular thread--you want to know when the memory changed, whatever
> thread did it.
Yes, agreed. But then we have some implementation problems, perf_event's
are always per-thread (although they have the "group" notion).
clone() should always inherit bps, probably not too hard to implement.
There real problem is attach-the-new-bp-to-the-process, we don't have the
sleeping lock to process all threads and protect the race with clone().
And ptrace_detach/release_task, we can't destroy perf_event under tasklist.
(and the current task->ptrace_bps code is buggy and imho ugly).
Of course, I am not saying this is impossible, I am just trying to
understand the possible problems.
Now, let's forget about the implementation details. First of all, we
can't really make the per-process-bp API, bp shouldn't affect the threads
we do not ptrace. So, per-process should mean the threads we do ptrace.
In this case it is not clear what should represent the process. OK,
I think this is minor.
> If the hw_breakpoint interfaces also support (or will support) the
> hardware-assisted code breakpoints,
Looking at the code, I think it does... X86_BREAKPOINT_EXECUTE. But
again, I didn't verify.
> They are so limited that you always need
> to fall back to traditional text-inserted breakpoints
I forgot everything I learned when I reviewed uprobes patches. But iirc,
they will have perf_event interface as well.
To summarize: I still have no idea about how this API should look ;)