[Bug tdep/34519] RISC-V: GDB crashes when disassembling elf32-bigriscv produced by -mbig-endian, and remote PC is byte-swapped

https://sourceware.org/bugzilla/show_bug.cgi?id=34519

--- Comment #3 from liu xu <mumuxi_ll at outlook dot com> ---
(In reply to Tom Tromey from comment #1)
> Could you try the gdb 18 pre-release or git master?
> 
> Also, could you attach a small executable (as small as you
> can manage) that shows the problem?  That might be helpful.

hi, maintainer,

I have reproduced a RISC-V big-endian remote debugging register endian issue
with GDB 18.0.90.

The attached be-gdb-min.elf is a 244-byte stripped elf32-bigriscv executable.
It has one .text segment loaded at 0x80000000 and does not use libc, libgcc,
startup files, or an SDK.

Offline GDB disassembly works correctly and GDB recognizes the file as
elf32-bigriscv. However, when debugging a big-endian RISC-V target through the
remote protocol, register values appear byte-swapped.

Here is the log：
=====================================================
(gdb) target remote :1234
Remote debugging using :1234
0x04100000 in ?? ()
(gdb) show endian
The target endianness is set automatically (currently big endian).
(gdb) show architecture 
The target architecture is set to "auto" (currently "riscv:rv32").
(gdb) info files 
Symbols from "/tmp/riscv-gdb-be-upstream-reproducer/be-gdb-min.elf".
Remote target using gdb-specific protocol:
        `/tmp/riscv-gdb-be-upstream-reproducer/be-gdb-min.elf', file type
elf32-bigriscv.
        Entry point: 0x80000000
        0x80000000 - 0x80000016 is .text
        While running this, GDB does not access memory from...
Local exec file:
        `/tmp/riscv-gdb-be-upstream-reproducer/be-gdb-min.elf', file type
elf32-bigriscv.
        Entry point: 0x80000000
        0x80000000 - 0x80000016 is .text
(gdb) x/6i 0x80000000
   0x80000000:  lui     sp,0x90000
   0x80000004:  addi    sp,sp,256
   0x80000006:  auipc   ra,0x0
   0x8000000a:  jalr    10(ra)
   0x8000000e:  j       0x8000000e
   0x80000010:  li      a0,1
(gdb) hbreak *0x80000010
Hardware assisted breakpoint 1 at 0x80000010
(gdb) continue 
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x10000080 in ?? ()
(gdb) info registers pc sp a0
pc             0x10000080       0x10000080
sp             0x10090  0x10090
a0             0x0      0
(gdb) set $a0 = 0x12345678
(gdb) info registers a0
a0             0x78563412       2018915346
(gdb) si
0x12000080 in ?? ()
(gdb) 
0x14000080 in ?? ()
================================================

A hardware breakpoint is set at 0x80000010. After continue, GDB reports PC as
0x10000080 instead of 0x80000010. After one si, GDB reports PC as 0x12000080
instead of 0x80000012. Also, after `set $a0 = 0x12345678`, `info registers a0`
reports 0x78563412.

This suggests the RISC-V big-endian remote register path is applying the wrong
byte order for register packets. The issue affects PC-dependent commands such
as frame/source-level stepping because GDB sees the current PC outside the
function address range.

-- 
You are receiving this mail because:
You are on the CC list for the bug.