This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]