RISC-V Remote Target Support? #598
Comments
|
Risc 5 is supported, it's just not detecting it properly. Try setting it manually: You're not giving us a lot to go on. Take a look and try to see why it's not detecting it. |
|
If you are using gdb >= 10.1 then this incorrect detection is probably due to #594, which should be fixed soon. |
|
Ah yup. gdb 10.1 I should note that running the non-gef specific |
|
Thank you. Would you be able to check out that commit to verify that it fixes the issue for you? Thanks |
|
@Grazfather hm.. maybe I closed this one too soon :-) Using the latest gef from dev.... |
|
To be honest.. things have gotten a bit worse: Not calling pi set_arch("riscv") Here are the valid riscv architectures: |
|
Here's the raw GDB stub output from qemu-system-riscv64. I hate it 😆 $qXfer:features:read:target.xml:0,4096#1E
+$l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><xi:include href="riscv-64bit-cpu.xml"/><xi:include href="riscv-64bit-fpu.xml"/><xi:include href="riscv-64bit-csr.xml"/><xi:include href="riscv-64bit-virtual.xml"/></target>#68There's no "<architecture>" defined there from the qemu code. Looking at qemu's gdbstub... if (strncmp(p, "target.xml", len) == 0) {
char *buf = process->target_xml;
const size_t buf_sz = sizeof(process->target_xml);
/* Generate the XML description for this CPU. */
if (!buf[0]) {
GDBRegisterState *r;
pstrcat(buf, buf_sz,
"<?xml version=\"1.0\"?>"
"<!DOCTYPE target SYSTEM \"gdb-target.dtd\">"
"<target>");
if (cc->gdb_arch_name) {
gchar *arch = cc->gdb_arch_name(cpu);
pstrcat(buf, buf_sz, "<architecture>");
pstrcat(buf, buf_sz, arch);
pstrcat(buf, buf_sz, "</architecture>");
g_free(arch);
}So it looks like qemu isn't setting gdb_arch_name for riscv. Looking through the qemu source code... Oops... a really recent addition :-) So.. it looks like gdb is calling no architecture defined in the target.xml as "auto" gef might want to handle "auto" with some special warning case :-) |
|
I compiled qemu 6.0, and it indeed reports architecture now... $qXfer:features:read:target.xml:0,4096#1E
+$l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><architecture>riscv:rv64</architecture><xi:include href="riscv-64bit-cpu.xml"/><xi:include href="riscv-64bit-fpu.xml"/><xi:include href="riscv-64bit-virtual.xml"/><xi:include href="riscv-csr.xml"/></target>#6eNow gef shows: A quick patch to gef: [kallisti5@eris generated.riscv64]$ diff -Naur ~/.gdbinit-gef-stock.py ~/.gdbinit-gef.py
--- /home/kallisti5/.gdbinit-gef-stock.py 2021-04-14 08:43:21.201598648 -0500
+++ /home/kallisti5/.gdbinit-gef.py 2021-04-14 08:44:00.975034941 -0500
@@ -6320,6 +6320,9 @@
elif arch.startswith("sparc"):
current_elf.e_machine = Elf.SPARC
current_arch = SPARC()
+ elif arch.startswith("riscv"):
+ current_elf.e_machine = Elf.RISCV
+ current_arch = RISCV()
else:
raise RuntimeError("unsupported architecture: {}".format(arch))
Back to the original error 😠 under qemu 6.0 |
|
You'll have to break this into separate issue. Can you debug risc5 locally? What are you using as your riscv target? Do you have some easy qemu setup I could use to reproduce. |
|
to reproduce, However for the fix I mentioned above, you might have to compile qemu-system-riscv64 6.x from upstream qemu. I've attached my qemu 6.x qemu-system-riscv64, but it likely won't help much if you don't have matching system libraries to run it |
|
Yes, I have that, I'll have to take some time to get a linux system running in it, it's just not a priority for me right now. |
|
JFYI, AFAICT running an OS within qemu is not required to investigate the problem. The parameters he mentioned halt the CPU at reset and one can use gdb to run a bare-metal binary. This is a common setup for embedded systems/microcontrollers (where you also debug via GDB's remote function and a gdb server stub running in a hardware debugger dongle. This will be less useful with riscv64 but for riscv32 microcontrollers. (I am working on hw security mechanisms on these thus my interest in this issue ;) |
|
I do not have this same issue (years later 😅). I am using this dockerfile to install both qemu and gdb with riscv64 support. It still isn't perfect, because it doesn't know how to map the stack, but I think that's another issue. If any of you are still using riscv, I would be curious to understand how it's behaving for you now. |
and others
Is your feature request related to a problem? Please describe.
Looking for RISC-V support :-)
The text was updated successfully, but these errors were encountered: