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.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1261564 - HW watchpoints not set correctly on aarch64
Summary: HW watchpoints not set correctly on aarch64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdb
Version: 7.2
Hardware: aarch64
OS: Linux
medium
medium
Target Milestone: rc
: 7.3
Assignee: Jan Kratochvil
QA Contact: qe-baseos-tools-bugs
Robert Krátký
URL:
Whiteboard:
Depends On:
Blocks: 1270165 1277314 1297579 1313485 1347993 1352563 1579522
TreeView+ depends on / blocked
 
Reported: 2015-09-09 16:57 UTC by Miroslav Franc
Modified: 2018-05-17 20:35 UTC (History)
8 users (show)

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.
Clone Of:
: 1347993 (view as bug list)
Environment:
Last Closed: 2016-11-04 03:49:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
self-contained reproducer (deleted)
2015-09-09 16:57 UTC, Miroslav Franc
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2328 0 normal SHIPPED_LIVE gdb bug fix and enhancement update 2016-11-03 13:44:08 UTC

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


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