From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2205) id 69916384EF66; Sat, 10 Dec 2022 14:40:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69916384EF66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1670683238; bh=ClBk9KWemQAuqB0qPcGGs1Ict5SiAiibYLOfNcgtwVw=; h=From:To:Subject:Date:From; b=kkg7SI8ohF5JVG0P6pT6i7jpNs4CjzSK1yqkVewow00cend9rWGI1Ah+AUzMJbOM2 0KmPpRkM3PIx9WlKD9V05RjMZhPJJr9slAzvI+c4YJEuyaFyq7KR6vQhz27NaQSgz3 R2VBimDhx8h5LD2UmLtiQo/nBkAwio0YClFqsUqk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Tom de Vries To: gdb-cvs@sourceware.org Subject: [binutils-gdb] [gdb/tdep] Fix larl handling in s390_displaced_step_fixup X-Act-Checkin: binutils-gdb X-Git-Author: Tom de Vries X-Git-Refname: refs/heads/master X-Git-Oldrev: b813665fd2ec3a5cbe7cbc8b36ce7aa0271dec44 X-Git-Newrev: 823b2395e449f87ab9f68027c7ed38ec0eea4025 Message-Id: <20221210144038.69916384EF66@sourceware.org> Date: Sat, 10 Dec 2022 14:40:38 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D823b2395e449= f87ab9f68027c7ed38ec0eea4025 commit 823b2395e449f87ab9f68027c7ed38ec0eea4025 Author: Tom de Vries Date: Sat Dec 10 15:40:34 2022 +0100 [gdb/tdep] Fix larl handling in s390_displaced_step_fixup =20 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 =3D 0x804006b0 ^M (gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr ... =20 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 =20 Breakpoint 1, main () at scm-lazy-string.c:23 23 const char *ptr =3D "pointer"; +step 24 const char array[] =3D "array"; +print ptr $1 =3D 0x804006b0 ... =20 If we delete the breakpoint after running to it, we have instead the ex= pected: ... +delete +step 24 const char array[] =3D "array"; +print ptr $1 =3D 0x4006b0 "pointer" ... =20 The problem is in displaced stepping, forced by the presence of the bre= akpoint, when stepping over this insn: ... 0x4005d2 larl %r1,0x4006b0 ... =20 With normal stepping we have: ... (gdb) p /x $r1 $2 =3D 0x3ff004006b0 ... but with displaced stepping we have instead (note the 0x80000000 differ= ence): ... (gdb) p /x $r1 $1 =3D 0x3ff804006b0 (gdb) ... =20 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. =20 Fix this by removing the "amode |". =20 Tested on s390-linux, with native and target board unix/-m31. =20 Approved-By: Ulrich Weigand Diff: --- gdb/s390-tdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/s390-tdep.c b/gdb/s390-tdep.c index d0dba7654bb..2486ecdcb3a 100644 --- a/gdb/s390-tdep.c +++ b/gdb/s390-tdep.c @@ -557,7 +557,7 @@ s390_displaced_step_fixup (struct gdbarch *gdbarch, regcache_write_pc (regs, from + insnlen); /* Recompute output address in R1. */ regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1, - amode | (from + i2 * 2)); + from + i2 * 2); } =20 /* If we executed a breakpoint instruction, point PC right back at it. = */