This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]