Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
*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.
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]
---------------------------------------------
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.
(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. :^)
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.
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
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] ---------------------------------------------