You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[gdb/tdep] Fix larl handling in s390_displaced_step_fixup
On s390x-linux with target board unix/-m31, I run into:
...
(gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length
print ptr^M
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
(gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr
...
A minimal example is:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+file scm-lazy-string
+break main
Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23.
+run
Breakpoint 1, main () at scm-lazy-string.c:23
23 const char *ptr = "pointer";
+step
24 const char array[] = "array";
+print ptr
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
...
If we delete the breakpoint after running to it, we have instead the expected:
...
+delete
+step
24 const char array[] = "array";
+print ptr
$1 = 0x4006b0 "pointer"
...
The problem is in displaced stepping, forced by the presence of the breakpoint,
when stepping over this insn:
...
0x4005d2 <main+10> larl %r1,0x4006b0
...
With normal stepping we have:
...
(gdb) p /x $r1
$2 = 0x3ff004006b0
...
but with displaced stepping we have instead (note the 0x80000000 difference):
...
(gdb) p /x $r1
$1 = 0x3ff804006b0
(gdb)
...
The difference comes from this code in s390_displaced_step_fixup:
...
/* Handle LOAD ADDRESS RELATIVE LONG. */
else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2))
{
/* Update PC. */
regcache_write_pc (regs, from + insnlen);
/* Recompute output address in R1. */
regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
amode | (from + i2 * 2));
}
...
where the "amode |" adds the 0x80000000.
Fix this by removing the "amode |".
Tested on s390-linux, with native and target board unix/-m31.
Approved-By: Ulrich Weigand <[email protected]>
0 commit comments