From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 534F83858D39; Sun, 18 Jun 2023 09:38:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 534F83858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1687081132;
	bh=ipFq5dtxPkaYc1/KLwiZUNNt3QCLH11IH5RNU/bFt7A=;
	h=From:To:Subject:Date:From;
	b=ebRn2CMjmU8ZCBmuUJwg+vFuvPTFqrPljKLrY6BetTdZIYwiJv7wBZMBDGpVnh6O+
	 WFGKMnsCWuDuNP+zXd9dfV/C/Mymx2F4nDxHQZjNa4xmlhmZfB5a0abmQVVXyriBJ4
	 8vaVVydE+bpq7wPvrJUfymorVpM+n68J197pvHl8=
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/30562] New: [gdb] FAIL: gdb.threads/watchthreads2.exp:
 watch x
Date: Sun, 18 Jun 2023 09:38:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-30562-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

            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 int=
o:
...
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 watchpoin=
t to
be a software watchpoint.  This makes the test-case rather slow (30 sec), b=
ut
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 =3D 0;
...
and this call returns something < 0 in the case where we set a hw breakpoin=
t.

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

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