This is the mail archive of the
mailing list for the Archer project.
Re: hw_breakpoint userland interface
> Yes. Firstly we need to know what would be more convenient for those
> who will actually use the new interface.
> 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.
If the hw_breakpoint interfaces also support (or will support) the
hardware-assisted code breakpoints, then there it is probably desired to
have thread-specific breakpoint support. But it's not clear to me that
serious userland users like GDB would really make use of any hardware-based
code breakpoints any time soon. They are so limited that you always need
to fall back to traditional text-inserted breakpoints and I'm not sure it's
deemed worthwhile to put effort into hardware-based code breakpoints for
the small number of cases they can address.