Hello Pedro,

I've replied to your comments and attached a v2 patch.

Le 3/19/18 à 3:28 PM, Pedro Alves a écrit :
> A few things are missing here:
> 
> #1 - kernel versions where this was observed.
> 

CentOS: 2.6.18-419.el5
Suse: 2.6.27.19-5-pae

> #2 - If it's not equal to TRAP_HWBKPT, then what's it equal to?
>       I assume zero?

No, it's equal to 1.

> Take a look at the big comment and table in nat/linux-ptrace.h -- is
> this is the only case that is different on these kernels?
> 

AFAIK, yes.

> I think that we should update the table a bit here, at least
> something like:
> 
>   -   | hardware breakpoints/watchpoints         | TRAP_HWBKPT |
>   +   | hardware breakpoints/watchpoints         | TRAP_HWBKPT (*) |
> 
>   (*) - Kernels x.y.z (CentOS 5, Suse 11) leave this as zero > If other cases are different, then that might affect how to best
> address this.
> 

Agree.

> This comment only makes complete sense with the context in the
> git log in mind:
> 
> - This code is run by all architectures, so the comment should mention x86.
> - The comment reads a bit backwards to me -- talks about what it should
>    be before talking about watchpoints.
> 
> I'd suggest something like this:
> 
>     /* On some kernels (such as x86-64 x.y.z/CentOS 5, x.y.z/Suse 11),
>        when we continue into a watchpoint, si_code indicates 0 instead of
>        TRAP_HWBKPT so we need to check debug registers separately.  */
> 
Agree.

> Does the step-into-watchpoint case result in TRAP_TRACE, or does
> that result in 0 too?  That affects the "continue" in the comment above.

This results to a value of 1 too.

> Thanks,
> Pedro Alves
> 

Regards