[LLDB] s390x, incorrect byte order issues with `Cast` and `p/x $pc`

[patryk4815]

Version: lldb 20.1.1

Reproduction:

qemu-s390x -g 1234 ./hello

Other terminal:

(lldb) file ./hello
(lldb) gdb-remote 0:1234
(lldb) b main
Breakpoint 1: where = hello`main, address = 0x0000000001002228
(lldb) c
Process 3281862 resuming
Process 3281862 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x0000000001002228 hello`main
hello`main:
    0x1002228 <+0>:  ear    %r1, %a0
    0x100222c <+4>:  sllg   %r4, %r1, 32
    0x1002232 <+10>: stmg   %r6, %r15, 48(%r15)
    0x1002238 <+16>: ear    %r4, %a1
(lldb) register read pc
    pswa = 0x0000000001002228  hello`main
(lldb) p/x $pc
(unsigned long) 0x2822000100000000
(lldb)

The bug occurs for all registers, not just the $pc
p/x $pc should show 0x0000000001002228, but instead I see: 0x2822000100000000

We discovered this bug while implementing s390x support in Pwndbg

In [20]: value = pwndbg.regs.by_name('r14')

In [21]: hex(int(value))
Out[21]: '0x7fb84143554a'

In [22]: hex(int(value.cast(pwndbg.aglib.typeinfo.unsigned)))
Out[22]: '0x4a554341b87f0000'

In [23]: pwndbg.aglib.typeinfo.unsigned.inner
Out[23]: unsigned long long

Basically internal lldb.SBValue Cast function mess-up byte-ordering somehow.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (patryk4815)

Version: `lldb 20.1.1`

Reproduction:

qemu-s390x -g 1234 ./hello

Other terminal:

(lldb) file ./hello
(lldb) gdb-remote 0:1234
(lldb) b main
Breakpoint 1: where = hello`main, address = 0x0000000001002228
(lldb) c
Process 3281862 resuming
Process 3281862 stopped
* thread #<!-- -->1, stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x0000000001002228 hello`main
hello`main:
    0x1002228 &lt;+0&gt;:  ear    %r1, %a0
    0x100222c &lt;+4&gt;:  sllg   %r4, %r1, 32
    0x1002232 &lt;+10&gt;: stmg   %r6, %r15, 48(%r15)
    0x1002238 &lt;+16&gt;: ear    %r4, %a1
(lldb) register read pc
    pswa = 0x0000000001002228  hello`main
(lldb) p/x $pc
(unsigned long) 0x2822000100000000
(lldb)

The bug occurs for all registers, not just the $pc
p/x $pc should show 0x0000000001002228, but instead I see: 0x2822000100000000

We discovered this bug while implementing s390x support in Pwndbg

In [20]: value = pwndbg.regs.by_name('r14')

In [21]: hex(int(value))
Out[21]: '0x7fb84143554a'

In [22]: hex(int(value.cast(pwndbg.aglib.typeinfo.unsigned)))
Out[22]: '0x4a554341b87f0000'

In [23]: pwndbg.aglib.typeinfo.unsigned.inner
Out[23]: unsigned long long

Basically internal lldb.SBValue Cast function mess-up byte-ordering somehow.

[DavidSpickett]

Thanks for raising this, I was about to try to use big endian support for something else and wondered if I could copy what s390x was doing, apparently not :)

To reproduce on Ubuntu:

$ sudo apt install qemu-user gcc-s390x-linux-gnu
$ cat main.c
int main() {
  return 0;
}
$ cat makefile
all:
        s390x-linux-gnu-gcc main.c -o test -g -static

debug:
        qemu-s390x -g 1234 ./test
$ make
$ make debug

Using latest lldb (e12681a):

$ ./bin/lldb ~/test_s390x/test
(lldb) target create "/home/david.spickett/test_s390x/test"
Current executable set to '/home/david.spickett/test_s390x/test' (s390x).
(lldb) gdb-remote localhost:1234
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
    frame #0: 0x0000000001000848 test`_start
test`_start:
->  0x1000848 <+0>:  la     %r4, 8(%r15)
    0x100084c <+4>:  lg     %r3, 0(%r15)
    0x1000852 <+10>: lghi   %r0, -16
    0x1000856 <+14>: ngr    %r15, %r0
(lldb) b main
Breakpoint 1: where = test`main + 8 at main.c:2:10, address = 0x0000000001000a38
(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x0000000001000a38 test`main at main.c:2:10
   1    int main() {
-> 2      return 0;
   3    }
(lldb) process status
Process 1 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x0000000001000a38 test`main at main.c:2:10
   1    int main() {
-> 2      return 0;
   3    }
(lldb) register read pc
    pswa = 0x0000000001000a38  test`main + 8 at main.c:2:10
(lldb) p/x $pc
(unsigned long) 0x380a000100000000
(lldb) q

Same result, treated as a register it works, but got through an expression it appears reversed.

I suspect that it does not apply byte ordering at all, given that the order for $pc is the little endian order of my host. So we use that value during the expression, but of course, read in a big endian order in the debugee process, it comes out as a 64 bit integer the other way around. So I would guess that if you debugged s390x from s390x it would work, but only because the endian happen to match.

Registers are sort of "injected" into the expression context as needed, this is why it might retain the host endian. Vs. program variables used, or created, in the expression, which would be in the process' endian by default.

We don't have buildbots doing cross-endian testing, but I did write some little and big endian tests for register field work. Unfortunately that fake debug server setup won't allow us to JIT expressions.

Anyway, if the fix is clear and easy to hand test it shouldn't be a problem.

[DavidSpickett]

Normal variables seem to be ok:

(lldb) process status
Process 1 stopped
* thread #1, stop reason = step over
    frame #0: 0x0000000001000a60 test`main at main.c:5:10
   2      int a = 1;
   3      int b = 2;
   4      int c = a + b;
-> 5      return 0;
   6    }
(lldb) p/x $pc + (a + b)
(unsigned long) 0x600a000100000003

a+b is 3 as expected.

[whitequark]

Related to #138536?