Re: [RFA v2] (x86) Fix watchpoint using hardware breakpoint for some distro

[Pedro Alves <palves@redhat.com>]

On 03/21/2018 04:17 PM, Xavier Roirand wrote:
> Hello Pedro,
> 
> Le 3/20/18 à 4:11 PM, Pedro Alves a écrit :
>> On 03/20/2018 02:28 PM, Xavier Roirand wrote:
>> Hmm, that's TRAP_BRKPT nowadays.  What was '1' supposed to mean in
>> kernels of such vintage?  What was it's symbolic name back then?
> 
> As far as I can see in header file (/usr/include/bits/siginfo.h),
> this is the same value, it's:
> 
> TRAP_BRKPT = 1,        /* Process breakpoint.  */
> 
>> In the table in linux-ptrace.h, we see that modern kernels report
>> TRAP_BRKPT/1 for the "single-stepping a syscall" case.  What do
>> those older kernels report in that case then?
> 
> When "single-stepping" syscall, the same value (TRAP_BRKPT) is
> reported.
> 
>> What do those kernels report for hardware _breakpoints_?  Is it 1 too?
> 
> Yes, I've checked this and it's 1 also.
> 
>> Wondering whether we should make GDB_ARCH_IS_TRAP_HWBKPT return
>> true for 1 too...
>>
>> Please provide a more complete picture.
>>
> 
> Is it enough or do you think I need to provide more info ?
> 
Earlier you said that TRAP_HWBKPT was the only case that was different
from current kernels, but turns out that's not accurate.  And now
I'm left wondering what do those kernels report for the other cases
you haven't confirmed yet, like hw breakpoints, software breakpoints,
and regular single steps.  We need a complete picture to figure out
what the best fix is.

E.g., if hw breakpoints and watchpoints report the same si_code,
how do hw breakpoints work with your patch?

Thanks,
Pedro Alves