Bug 1261564 - HW watchpoints not set correctly on aarch64
HW watchpoints not set correctly on aarch64
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdb (Show other bugs)
7.2
aarch64 Linux
medium Severity medium
: rc
: 7.3
Assigned To: Jan Kratochvil
qe-baseos-tools
Robert Krátký
:
Depends On:
Blocks: 1270165 1277314 1297579 1313485 1347993 1352563
  Show dependency treegraph
 
Reported: 2015-09-09 12:57 EDT by Miroslav Franc
Modified: 2016-11-03 23:49 EDT (History)
8 users (show)

See Also:
Fixed In Version: gdb-7.6.1-86.el7
Doc Type: Bug Fix
Doc Text:
*GDB* no longer reports spurious SIGTRAP signals on the 64-bit ARM architecture Prior to this update, *GDB* reported spurious *SIGTRAP* signals when a false watchpoint was detected by the processor on the 64-bit ARM architecture. *GDB* can now detect a hardware reason why the SIGTRAP signal occurred, and spurious *SIGTRAP* signals are no longer reported when hardware watchpoints are in use.
Story Points: ---
Clone Of:
: 1347993 (view as bug list)
Environment:
Last Closed: 2016-11-03 23:49:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
self-contained reproducer (268 bytes, text/plain)
2015-09-09 12:57 EDT, Miroslav Franc
no flags Details

  None (edit)
Description Miroslav Franc 2015-09-09 12:57:36 EDT
Created attachment 1071849 [details]
self-contained reproducer

Description of problem:
ISTM that sometimes hardware watchpoints are not set correctly on armv8.  I have a program and when debugging it I set read watchpoint at 4 byte variable and that triggers sigtrap even when the program reads a variable 4 bytes before that in memory.


Version-Release number of selected component (if applicable):
gdb-7.6.1-78.el7.aarch64
kernel-4.2.0-0.rc6.19.el7.aarch64


How reproducible:
always


Steps to Reproduce:
0. fetch reproducer from bugzilla
1. bash hw_watchpoints.sh

I set a read watchpoint on r on 0x420024, but that triggers sigtrap when reading d from 0x420020.  It does now work if the addresses are reversed.  It also disappears when I read from 0x420028.

By looking at the disassembly it looks to me like the program is doing 32 bit aligned load/stores.  And it's not loading from 0x420024.

9         r=d;
   0x00000000004005e0 <+48>:    adrp    x0, 0x420000 <__libc_start_main@got.plt>
   0x00000000004005e4 <+52>:    add     x0, x0, #0x20
   0x00000000004005e8 <+56>:    ldr     w1, [x0]
   0x00000000004005ec <+60>:    adrp    x0, 0x420000 <__libc_start_main@got.plt>
   0x00000000004005f0 <+64>:    add     x0, x0, #0x24
   0x00000000004005f4 <+68>:    str     w1, [x0]



Actual results:
---------------------------------------------
Temporary breakpoint 1 at 0x4005b0: file aarch64.c, line 5.

Temporary breakpoint 1, main () at aarch64.c:5
5         p=1;
Hardware read watchpoint 2: r
$1 = (int *) 0x420028 <p>
$2 = (int *) 0x420024 <r>
$3 = (int *) 0x420020 <d>
9         r=d;

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000004005ec in main () at aarch64.c:9
9         r=d;
---------------------------------------------


Expected results:
---------------------------------------------
Temporary breakpoint 1 at 0x4005b0: file aarch64.c, line 5.

Temporary breakpoint 1, main () at aarch64.c:5
5         p=1;
Hardware read watchpoint 2: r
$1 = (int *) 0x420028 <p>
$2 = (int *) 0x420024 <r>
$3 = (int *) 0x420020 <d>
9         r=d;
[Inferior 1 (process 19894) exited normally]
---------------------------------------------
Comment 2 Jan Kratochvil 2015-10-20 07:36:15 EDT
Fix:
963f9c80cb3f12fb779cf3189072ac48946da96c is the first bad (=good) commit
commit 963f9c80cb3f12fb779cf3189072ac48946da96c
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Oct 15 20:18:30 2014 +0100
    Rewrite non-continuable watchpoints handling
Subject: [PATCH v2 2/8] Rewrite non-continuable watchpoints handling
Message-Id: <1412344458-31774-3-git-send-email-palves@redhat.com>
Comment 3 Robert Krátký 2015-11-18 07:31:29 EST
Hi Jan,

One question about the suggested workarounds: Instead of offering to install upstream GDB, would it be OK to suggest using the version of GDB from RH DTS (7.10)?

Thanks.
Comment 4 Jan Kratochvil 2015-11-18 07:57:07 EST
(In reply to Robert Krátký from comment #3)
> One question about the suggested workarounds: Instead of offering to install
> upstream GDB, would it be OK to suggest using the version of GDB from RH DTS
> (7.10)?

No, because this Bug is about aarch64 while DTS ships only for x86_64. :^)
Comment 7 Jan Kratochvil 2016-03-06 09:46:52 EST
QA: The problem happens also on ppc64 but there it is correct as the compiled code really reads the 'r' variable:

  r=d;
    10000590:   60 00 00 00     nop
    10000594:   39 22 80 68     addi    r9,r2,-32664
    10000598:   81 29 00 00     lwz     r9,0(r9)
    1000059c:   7d 2a 07 b4     extsw   r10,r9
    100005a0:   60 00 00 00     nop
    100005a4:   39 22 80 6c     addi    r9,r2,-32660
    100005a8:   91 49 00 00     stw     r10,0(r9)
infrun: stop_pc = 0x1000059c
Hardware read watchpoint 2: r
Value = 2
0x000000001000059c in main () at aarch64.c:9
9         r=d;

Therefore on ppc64 it is not fixed.
Comment 9 Jan Kratochvil 2016-03-15 13:04:40 EDT
QA: New testfile: gdb.base/rhbz1261564-aarch64-watchpoint.exp
Test it both natively (linux-nat) and with gdbserver.
Comment 19 Robert Krátký 2016-08-20 11:21:14 EDT
Hi Jan,

Could you please check the Release Notes text?

Thank you.
Comment 20 Jan Kratochvil 2016-08-21 01:16:54 EDT
Fine with the Release Notes text, thanks.
Comment 22 errata-xmlrpc 2016-11-03 23:49:28 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2328.html

Note You need to log in before you can comment on or make changes to this bug.