From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 05AEC3858424; Sun, 7 Jan 2024 13:34:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05AEC3858424 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1704634457; bh=wivw3mqHSg4xyX/XnF6qg5bJsFnwexYXkfdlJaoSuC8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JBSNFESJmOdFgS9x8OW4PjnkM/kcnNXHyULQnkzF+CjoNPHCjOTFAKRz0U06CJck+ mZ9L+zh3/HV0aBW/+YjKcSy+ggNbcG/DU0c1b5i/Ia4fQgD82mt3CcC9a0zKLoHOBk NGnMooGrG7YwL/UdUOH5pdvB5++xPS3LOolu8kAc= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/31214] [gdb, aarch64] FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: continue Date: Sun, 07 Jan 2024 13:34:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 15.1 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: Message-ID: In-Reply-To: References: 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: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31214 --- Comment #1 from Tom de Vries --- Minimal example: ... $ gdb -q -batch \ -iex "set trace-commands on" \ outputs/gdb.base/watch-bitfields/watch-bitfields \ -ex start \ -ex "maint set show-debug-regs off" \ -ex "watch -location q.a" \ -ex "watch -location q.e" \ -ex continue \ -ex continue=20 +start Temporary breakpoint 1 at 0x4101a8: file /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c, line 33. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:33 33 q.a =3D 1; +maint set show-debug-regs off +watch -location q.a Hardware watchpoint 2: -location q.a +watch -location q.e Hardware watchpoint 3: -location q.e +continue Hardware watchpoint 2: -location q.a Old value =3D 0 New value =3D 1 main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:34 34 q.b =3D 2; +continue Hardware watchpoint 2: -location q.a Old value =3D 1 New value =3D 0 main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:42 42 q.h--; ... The code contains: ... q.a =3D 1; ... q.e =3D 5; ... There are two continues, and first one is supposed to trigger the watchpoin= t on q.a, and the second one is supposed to trigger the watchpoint on q.e. The problem is that the watchpoint on q.e doesn't trigger. The layout of q is: ... (gdb) ptype /o q /* offset | size */ type =3D struct foo { /* 0: 0 | 8 */ unsigned long a : 1; /* 0: 1 | 1 */ unsigned char b : 2; /* 0: 3 | 8 */ unsigned long c : 3; /* XXX 2-bit hole */ /* 1: 0 | 1 */ char d : 4; /* 1: 4 | 4 */ int e : 5; /* 2: 1 | 1 */ char f : 6; /* 2: 7 | 4 */ int g : 7; /* 3: 6 | 8 */ long h : 8; /* XXX 2-bit padding */ /* XXX 3-byte padding */ /* total size (bytes): 8 */ } ... Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1 and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should watch bytes 1 and 2. Using "maint set show-debug-regs on" we get: ... WP2: addr=3D0x440028 (orig=3D0x440029), ctrl=3D0x000000d5, ref.count=3D1 ctrl: enabled=3D1, offset=3D1, len=3D2 WP3: addr=3D0x440028 (orig=3D0x440028), ctrl=3D0x00000035, ref.count=3D1 ctrl: enabled=3D1, offset=3D0, len=3D1 ... which matches that. When writing to q.a, a hw watchpoint trap happens, and aarch64_stopped_data_address is called with trap_addr =3D=3D 0x440028, whic= h is mapped to WP3, and so the stopped data address (*addr_p) is reported as 0x440028, which is then mapped to gdb's q.a watchpoint. Since q.a has chan= ged value, it's reported. When writing to q.e, the same happens: a hw watchpoint trap happens, and aarch64_stopped_data_address is called with trap_addr =3D=3D 0x440028, whic= h is mapped to WP3, and so the stopped data address (*addr_p) is reported as 0x440028, which again is mapped to gdb's q.a watchpoint. Since q.a hasn't changed, it's ignored. The problem is that aarch64_stopped_data_address cannot distinguish between= WP2 and WP3. The fact that WP3 is chosen in both cases, is because it's checked first. Put differently, aarch64_stopped_data_address should report back 0x440028 a= nd 0x440029 in both cases, and the caller should figure out which of the two is actually triggered. Alternatively, it could report back a range [0x440028-0x44002a]. --=20 You are receiving this mail because: You are on the CC list for the bug.=