[binutils-gdb] [gdb/tdep] Fix larl handling in s390_displaced_step_fixup

[Tom de Vries <vries@sourceware.org>]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=823b2395e449f87ab9f68027c7ed38ec0eea4025

commit 823b2395e449f87ab9f68027c7ed38ec0eea4025
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Dec 10 15:40:34 2022 +0100

    [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 <uweigand@de.ibm.com>

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);
     }
 
   /* If we executed a breakpoint instruction, point PC right back at it.  */