Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1261564

Summary: HW watchpoints not set correctly on aarch64
Product: Red Hat Enterprise Linux 7 Reporter: Miroslav Franc <mfranc>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact: Robert Krátký <rkratky>
Priority: medium    
Version: 7.2CC: gdb-bugs, jan.kratochvil, jfeeney, lkuprova, mcermak, ohudlick, rkratky, sergiodj
Target Milestone: rc   
Target Release: 7.3   
Hardware: aarch64   
OS: Linux   
Whiteboard:
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-04 03:49:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1270165, 1277314, 1297579, 1313485, 1347993, 1352563, 1579522    
Attachments:
Description Flags
self-contained reproducer none

Description Miroslav Franc 2015-09-09 16:57:36 UTC
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>
   0x00000000004005e4 <+52>:    add     x0, x0, #0x20
   0x00000000004005e8 <+56>:    ldr     w1, [x0]
   0x00000000004005ec <+60>:    adrp    x0, 0x420000 <__libc_start_main>
   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 11:36:15 UTC
Fix:
963f9c80cb3f12fb779cf3189072ac48946da96c is the first bad (=good) commit
commit 963f9c80cb3f12fb779cf3189072ac48946da96c
Author: Pedro Alves <palves>
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>

Comment 3 Robert Krátký 2015-11-18 12:31:29 UTC
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 12:57:07 UTC
(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 14:46:52 UTC
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 17:04:40 UTC
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 15:21:14 UTC
Hi Jan,

Could you please check the Release Notes text?

Thank you.

Comment 20 Jan Kratochvil 2016-08-21 05:16:54 UTC
Fine with the Release Notes text, thanks.

Comment 22 errata-xmlrpc 2016-11-04 03:49:28 UTC
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