[Bug gdb/30562] New: [gdb] FAIL: gdb.threads/watchthreads2.exp: watch x

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30562

            Bug ID: 30562
           Summary: [gdb] FAIL: gdb.threads/watchthreads2.exp: watch x
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On a pinebook (debian 9, arm 64-bit kernel, arm 32-bit userland), I ran into:
...
FAIL: gdb.threads/watchthreads2.exp: watch x
FAIL: gdb.threads/watchthreads2.exp: x watch loop
...

First in more detail:
...
(gdb) watch x^M
Watchpoint 3: x^M
(gdb) FAIL: gdb.threads/watchthreads2.exp: watch x
...

Basically, the problem is that we get a software rather than hardware
watchpoint.

We can "fix" this by setting the watchpoint earlier, at the main breakpoint.

Alternatively, we can "fix" this in the test-case by allowing the watchpoint to
be a software watchpoint.  This makes the test-case rather slow (30 sec), but
OTOH after commenting out the printf it speeds up significantly (5 sec).

I looked into what the different is between setting the watchpoint earlier and
later, and the difference is in arm_linux_get_hwbp_cap, where we do:
...
      if (ptrace (PTRACE_GETHBPREGS, tid, 0, &val) < 0)
        available = 0;
...
and this call returns something < 0 in the case where we set a hw breakpoint.

I'd like to investigate this further using ptrace, but I'm not able to install
packages.  My plan is to install a new OS on the laptop, so I also may lose the
ability to reproduce this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.