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

[Yao Qi <qiyaoltc@gmail.com>]

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?

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.

-- 
Yao (齐尧)