Re: ptrace(2) interface for hardware watchpoints (breakpoints)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Dec 13, 2016 at 18:16:04 +0100, Kamil Rytarowski wrote:

> >> 4. Do not set watchpoints globally per process, limit them to
> >> threads (LWP). [...]  Adding process-wide management in the
> >> ptrace(2) interface calls adds extra complexity that should be
> >> pushed away to user-land code in debuggers.
> > 
> > I have no idea what amd64 debug registers do, but this smells like you
> > are exposing in the MI interface some of those details.  I don't think
> > this can be done in hardware on sh3, e.g.  

Ok, I was confused there for a moment.  The "debug state" is per-lwp
and is restored when lwp is switched to.  What was I thinking...


> > Also, you quite often have no idea which thread stomps on your data,
> > so I'd imagine most of the time you do want a global watchpoint.
> 
> This is true.
> 
> With the proposed interface per-thread a debugger can set the same
> hardware watchpoint for each LWP and achieve the same result. There are
> no performance or synchronization challenges as watchpoints can be set
> only when a process is stopped.
> 
> In my older code I had logic per-process to access watchpoints, but
> it required extra logic in thread-specific functions to access
> process specific data. I assumed that saving few dozens of CPU
> cycles before each thread entering user-space is precious. (I know
> it's a small optimization, however it's for free)

Again, you don't provide any details.  What extra logic?  Also, what
are these few dozens of instructions you are talking about?  I.e. what
is that extra work you have to do for a process-wide watchpoint that
you don't have to do for an lwp-specific watchpoint on each return to
userland?


> >> 5. Do not allow to mix PT_STEP and hardware watchpoint, in case of
> >> single-stepping the code, disable (it means: don't set) hardware
> >> watchpoints for threads. Some platforms might implement single-step with
> >> hardware watchpoints and managing both at the same time is generating
> >> extra pointless complexity.
> > 
> > I don't think I see how "extra pointless complexity" follows.
> 
> 1. At least in MD x86 specific code, watchpoint traps triggered with
> stepped code are reported differently to those reported with plain steps
> and also differently to plain hardware watchpoint traps. They are 3rd
> type of a trap.
>
> 2. Single stepping can be implemented with hardware assisted watchpoints
> (technically breakpoints) on the kernel side in MD. And if so, trying to
> apply watchpoints and singlestep will conflict and this will need
> additional handling on the kernel side.
> 
> To oppose extra complexity I propose to make stepping and watchpoints
> separable, one or the other, but not both.

And again you allude to MD details and don't provide any.  You cannot
just handwave this away.  You will have to provide enough information
for people to implement this for other arches evnentually, including
MD specifics that affected the design, so that people can see how
their MD specific details affect their implementation.  Why don't
provide this upfront?  I understand you might be eager to commit this
work and be done with it, but you are doing this fulltime.  Others
don't have this luxury.  So I don't want to come around to
implementing your desing in a few months time when I have some spare
cycles and discover that it's ill suited for the hardware I have to
deal with.

May be you are right, and it's hard to mix single-stepping and
watchpoints, but I don't have time to investigate this fully right now
for sh3 and you don't provide any details that will back your
conclusion for x86.  Have it occured to you that you might me missing
some approach to solving this, but people that grok x86 can't tell you
unless they know the details.  And I don't think that committing
first, as you seem to have done already, and then let people figure it
out from RTFS is an acceptable approach, b/c, again, without
description you force people to RTFS and they might not have the time.


> > Also, you might want both, single-stepping and waiting for a
> > watchpoint.  Will debugger have switch dynamically to software
> > watchpoints when single-stepping?  Can it even do that already?
> 
> My understanding of stepping the code is that we want to go one and only
> one instruction ahead (unless port restricts it and its 1 or more),
> followed with a break.
> 
> What's the use case of waiting for data access and stepping in the same
> time? Is it needed? Does it solve some issues that cannot be solved
> otherwise? Could it be implemented in software (in case of watch)?

Isn't it your job to tell us the answers?  So, let's say I set a
watchpoint and then I hit some other breakpoint and do some stepi.  If
one of those instructions I'm stepping will do the read/write I'm
watching for, how it will be detected y the debugger if you can't mix
hw-assisted watchpoints and single-stepping?


> My original intention was to make it friendly for ports, without too
> specific expectations with flexible

Again, you are not providing any details for people to meaningfully
comment on your proposal.


> > In general I'd appreciate if handwavy "this is pointless/extra
> > complexity" arguments were spelled out.  They might be obvious to you,
> > but most people reading this don't have relevant information swapped
> > in, or don't know enough details.
> 
> Thank you for your input, I hope I explained and expressed my thoughts
> more clearly.

No, you are not.

I'm distinctly unhappy with the way this is being handled so far.

-uwe