[Bug gdb/31214] [gdb, aarch64] FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: continue

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

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
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 
+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 = 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 = 0
New value = 1
main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:34
34        q.b = 2;
+continue

Hardware watchpoint 2: -location q.a

Old value = 1
New value = 0
main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:42
42        q.h--;
...

The code contains:
...
  q.a = 1;
  ...
  q.e = 5;
...

There are two continues, and first one is supposed to trigger the watchpoint 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 = 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=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1
  ctrl: enabled=1, offset=1, len=2
WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1
  ctrl: enabled=1, offset=0, len=1
...
which matches that.

When writing to q.a, a hw watchpoint trap happens, and
aarch64_stopped_data_address is called with trap_addr == 0x440028, which 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 changed
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 == 0x440028, which 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 and
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].

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