On Fri, 2018-03-16 at 17:53 -0300, Pedro Franco de Carvalho wrote:
> Michael Neuling <mikey@xxxxxxxxxxx> writes:
>
> > For ptrace, we now return an error if run on a POWER9. GDB gives this
> > error when you attempt to run a program with a breakpoint set on
> > POWER9:
> > "Unexpected error setting breakpoint or watchpoint: No such device."
>
> Thanks a lot for implementing this!
>
> Would it also make sense to have PPC_PTRACE_GETHWDBGINFO return
> dbginfo.num_data_bps = 0 if !breakpoint_available()? In this case GDB
> would work in a friendlier way, because it would transparently switch to
> software watchpoints.
If I do that, it looks like GDB falls back to software emulation (very sloooow)
of the watchpoint rather than failing with the error I gave before.
That's probably the better solution, so I'll do that... Thanks!
> Not sure what to do about .features in this case. I assume currently it
> only has PPC_DEBUG_FEATURE_DATA_BP_RANGE set and not the DAWR feature
> flag (since the cpu feature is disabled).
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.
Thanks for the catch.
Mikey
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
