Closed lbmeng closed 5 years ago
It works for me.
(gdb) disas main Dump of assembler code for function main: 0x000000000001044c <+0>: addi sp,sp,-16 0x000000000001044e <+2>: sd ra,8(sp) 0x0000000000010450 <+4>: sd s0,0(sp) 0x0000000000010452 <+6>: addi s0,sp,16 0x0000000000010454 <+8>: lui a5,0x10 0x0000000000010456 <+10>: addi a0,a5,1224 # 0x104c8 0x000000000001045a <+14>: jal ra,0x10390 puts@plt 0x000000000001045e <+18>: li a5,0 0x0000000000010460 <+20>: mv a0,a5 0x0000000000010462 <+22>: ld ra,8(sp) 0x0000000000010464 <+24>: ld s0,0(sp) 0x0000000000010466 <+26>: addi sp,sp,16 0x0000000000010468 <+28>: ret End of assembler dump. (gdb)
Jim, which branch should I test on?
I just noticed this was a qemu bug report not a gdb bug report, which leaves me a little confused. What does the gdb disassembler have to do with qemu? Maybe you are saying it doesn't work when gdb is talking to qemu? I didn't try that, but I wouldn't expect the result to be different. I just tried it now, and the result looks OK.
When you are asking about branches, are you asking about qemu branches or gdb branches?
For qemu, you probably want to use the default branch.
For gdb, it is complicated. We have two gdb ports, one in riscv-gnu-toolchain (default branch), and one in the FSF GDB development tree. The FSF GDB one is the preferred one, but doesn't have some openocd support yet, including the XML register set support, which you also need for qemu. We are in the process of fixing this. When fixed, the riscv-gnu-toolchain gdb port will die and be replaced with the FSF GDB port. So use the FSF GDB port if you can, and if you can't then use the riscv-gnu-toolchain port and expect it will change to the FSF one at some point.
Yes, it's a QEMU bug report not GDB. So what I was reporting was the using GDB remote debug to connect to QEMU, and with the disassemble command from GDB it does not show the compressed instructions correctly.
I was using a QEMU that was built from the riscv-gnu-toolchain repo, plus the XML register fixes and single step to CSR issue patch. I don't understand why I need the FSF GDB. I suspect the issue is with the GDB stub in the QEMU, just like the issue with the CSR issue I reported before.
Don't use the qemu in riscv-gnu-toolchain, it is an old obsolete and probably broken one. This is only for running the gcc testsuite. We have two glibc ports, the riscv-gnu-toolchain one and the FSF one. There were ABI changes when glibc was upstreamed. The FSF one has only the 64-bit support. The riscv-gnu-toolchain one has both 32 and 64-bit support and the old ABI. In order to test 32-bit linux toolchain support, we use the old glibc which requires the old qemu that supports the old ABI. Andes is in the process of submitting the 32-bit glibc support upstream, and when that is done riscv-gnu-toolchain will switch to the FSF glibc port, and also to an up-to-date qemu.
Meanwhile, if you want a working qemu for anything other than the gcc testsuite, you need to git clone riscv/riscv-qemu to get current qemu sources. I think the default branch already has the XML register fix and single step to CSR fix.
We hope the upstreaming mess in riscv-gnu-toolchain to all be fixed by next February when the next glibc and gdb releases are expected.
Thanks Jim. I will shoot another try with riscv/riscv-qemu.
BTW you mentioned old ABI and new ABI. What is that? I believe both 32-bit and 64-bit the ABI are documented @ https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md. Is that new or old?
The calling convention has not changed, but some stuff like the size and layout of the stat structure, and the format of exception handler stack frames has changed. So this is Linux kernel/glibc ABI stuff, not end user psABI stuff, but it is stuff that affects qemu.
Jim, I tried the default branch (riscv-all) in the riscv/riscv-qemu repo. It has the XML register fix but does not have the single step CSR fix.
Built a QEMU and tested the compressed instruction disassembly with GDB remote, it works.
Is this a known issue?