Re: [PING][PATCH PR gdb/21870] aarch64: Leftover uncleared debug registers

[Weimin Pan <weimin.pan@oracle.com>]

On 10/27/2017 2:05 AM, Yao Qi wrote:
> Wei-min Pan <weimin.pan@oracle.com> writes:
>
>> The most likely explanation is that ptrace() (1) does not validate contents
>> in either address or control register, and (2) uses some default
>> control values
>> when setting hardware breakpoints. (2) is the main reason that contents in
>> control register becomes non-zero after the aarch64_linux_set_debug_regs()
>> call. BTW the value of 0x1fc in control register is not random but can be
>> decoded as:
>>
>> "a watchpoint which is disabled, priv 2, 8-bytes, and of type hw_access"
> The test case we got from Jan (in PR 21870) is that parent forks a
> child, and read hw debug registers.  The parent asserts on some bits of
> debug registers read from child process.  They are zero when the program
> runs standalone, but they aren't zero after it runs within GDB.  When it
> runs in GDB, GDB is the grand-parent, in default, follow-fork-mode is
> parent, and detach-on-fork is on, IOW, GDB (as a grandparent) only
> attaches to the parent process, and leaves the child process run
> freely.  Then, the parent process reads some "unexpected" value from
> child process, why is it a bug in the grandparent process?

I believe that is because the grandparent process did modify the 
hardware registers in grandchild
process, which was originated from aarch64_linux_new_thread() that set 
new thread's registers
with DR_MARK_ALL_CHANGED().  It in turn caused 
aarch64_linux_set_debug_regs() to be called,
regardless of whether or not these registers had really been changed, 
when the grandchild process
was ready to resume execution.

> Secondly, why is it valid to expect 'length' is zero when the debug
> register is disabled?
>
>    assert (DR_CONTROL_LENGTH (dreg_state.dbg_regs[0].ctrl) == 0);
>
> GDB thinks if debug register is disabled, then, it can be used.  Now,
> the observation is that when a debug register is disabled, the 'length'
> can be different values in case that the process has tracer grandparent
> or not.  We may need to look into Linux kernel.
>

OK, but given that the ptrace() call made in 
aarch64_linux_set_debug_regs() to set debug registers
didn't flag any error, it suggested that kernel didn't do any 
verifications on input parameters?