Re: [PATCH v2] powerpc: Disable DAWR on POWER9

[Michael Neuling <mikey@neuling.org>]

On Tue, 2018-03-20 at 18:02 -0300, Pedro Franco de Carvalho wrote:
> I noticed that __set_breakpoint in process.c calls set_dabr if
> CPU_FTR_DAWR is not set. One case which could cause this to happen is if
> perf events are not configured (and CONFIG_HW_BREAKPOINT is not set),
> and someone calls ptrace with SET_DEBUGREG and data with a non-zero
> address and 0 in the RDWR bits. In this case set_bp will be false,
> thread.hw_brk will be set, and __switch_to will call __set_breakpoint,
> which will call set_dabr. I'm not sure what happens if mtspr with DARN
> is called on a P8.

This last sentence should read "I'm not sure what happens if mtspr with DABR is
called on a P9.", right?

If so, then it should be a nop, but we should fix it to make it clearer in the
code.

> > Yeah, currently you'll get PPC_DEBUG_FEATURE_DATA_BP_RANGE and no
> > PPC_DEBUG_FEATURE_DATA_BP_DAWR. 
> > 
> > If I set .features = 0 when !breakpoint_enabled() (as well as setting
> > num_data_bps = 0 above), GDB seems to not like it when I run the program on
> > P9:
> > 
> >     (gdb) r
> >     Starting program: /bin/true 
> >     Warning:
> >     Could not insert hardware watchpoint 1.
> >     Could not insert hardware breakpoints:
> >     You may have requested too many hardware breakpoints/watchpoints.
> >     (gdb)
> > 
> > So I think I'll leave this bits as I had in version 1 of the patch.
> 
> This would make existing GDB releases work nicely, but it should
> probably be fixed in GDB.
> 
> When .features is 0, GDB ignores the rest of the info returned by
> GETHWDBGINFO and assumes there will be at least one watchpoint register,
> which leads to the behavior you described, and doesn't seem correct
> (on the GDB side).

Yeah, agreed

Mikey