Re: [PATCH 3/3] [PowerPC] Fix debug register issues in ppc-linux-nat

[Pedro Franco de Carvalho <pedromfc at linux dot ibm dot com>]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:

>> I considered assuming that the kernel will always use a contiguous range
>> of slots from 1 to num_instruction_bps + num_data_bps, and always
>> deleting all these slots while ignoring ENODATA errors, but I'm not sure
>> if this is a very robust solution.  For instance, I inspected the kernel
>> code, and in embedded processors, if you set a ranged breakpoint, this
>> will occupy slots 1 and 2, and PPC_PTRACE_SETHWDEBUG will return slot 1.
>> You then have to use slot 1 as an argument to PPC_PTRACE_DELHWDEBUG to
>> delete the ranged breakpoint.  If you try to delete slot 2 before 1,
>> you'll get an EINVAL, and not an ENOENT.  If you delete 1 then 2, you'll
>> get ENOENT for 2.  I fact, this case means that the solution I proposed
>> in my previous reply of gathering all the slots from all threads in the
>> same thread group would not work well (we could get EINVALs).
>
> But it seems what would work reliably is to delete slots from 1 to max,
> while ignoring ENOENT, right?  In fact, you don't even need to know the
> max slot number, because you'll get EINVAL if and only if you're attempting
> to delete the first slot after max (assuming you do it in sequence).

I inspected the kernel code in more detail, and some configurations can
result in a non-contiguous range of slots after all.  For instance, some
embedded processor configurations with only two (instead of four)
hardware breakpoints will return slots 1 and 2 for these, and 5 and 6
for the hardware watchpoints.  Trying to delete slots 3 and 4 would
always return EINVAL.

To avoid tracking slots, we could try to delete slots in sequence, while
counting the number of successful deletions and ENOENT errors, and
ignoring EINVAL errors.  Once this count is equal to num_instruction_bps
+ num_data_bps, this should mean that we cleared all the debug
registers.

I don't think this is the way the interface was intended to be used (see
linux/Documentation/powerpc/ptrace.txt), since the slots sometimes
represent an event with more than one debug register, but it does
simplify how we handle this in GDB.  Note that we'll still have to keep
track of which slots that were installed by GDB are hardware
breakpoints, and not watchpoints, to differentiate them when we get a
trap (this is done in stopped_data_address).

Is this an acceptable solution, or should we keep track of installed
slots across clones and forks?  Should there be some limit to how many
EINVALs we see before we give up deleting the slots?

Thanks!

--
Pedro Franco de Carvalho