jim-wilson
commented
3 years ago The best place to find a gdb expert is on the FSF gdb mailing lists.
Note that riscv-gnu-toolchain builds binutils and gdb from separate binutils and gdb release branches. They are linked against different bfd builds built from different bfd versions. So checking whether objdump/nm/etc works isn't relevant to the gdb. You should try testing gdb itself, e.g. run gdb on a binary and try to disassemble code, without connecting to a target.
Though your gdb version number is odd. It looks like you are trying to build gdb from the binutils release branch. That isn't supported. You need to build gdb from a gdb release branch. If you do that, you will get a gdb 10.1 instead of the 10.0.50 etc that indicates a gdb development tree.
The gdb support for handling registers and the various riscv arch extensions has changed a number of times. It is possible something is broken, but you would have to file a bug upstream, and they won't like bugs against a random gdb development sources.
riscv-gnu-toolchain just recently upgraded from gdb 9.1 to gdb 10.1, so if gdb 10.1 isn't working you might try going back to gdb 9.1.
I'm working with RISC-V processor cores of both 64-bit (K210, QEmu) and 32-bit (GD32V, QEmu, BL602/SiFive) and it's super handy being able to use the same toolchain once installed with --with-multilib. Bravo for that feature! But that's a flag only to GCC to make, well, multiple libraries and not to GDB, right? (It doesn't seem to be accepted for, say, bfd)
The problem is that I generate a 32-bit binary for my GD32V core:
% file ../md0unix ../md0unix: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped
And once GDB hits either:
symbol-file ../md0unix or file ../md0unix
I get I'm sorry, Dave, I can't do that. Symbol format `elf32-littleriscv' unknown.
The error is coming from find_sym_fns()
This problem may come down to a configuration issue. It works as I expect in GNU gdb (SiFive GDB 8.3.0-2019.08.0) 8.3 but fails in the riscv/riscv-binusilt-gdb (and thus the Homebrew version) with me traveling back in source history even back to 2019-07 or so. This worked with some version from Homebrew, but going back in time with them to find a breaking point isn't so easy. So while I think this is a problem recent to Homebrew (w/in last 6 months or so) my experiments of just running git checkout; configure ; make (hack around build failures) repeat didn't support that theory. It fails in Homebrew's GNU gdb (GDB) 9.1 and it still fails as of GNU gdb (GDB) 10.0.50.20200724-git, which is making me think this isn't a transient thing at all. More importantly here, it's failing in builds from this tree.
Both say they were built "--host=x86_64-apple-darwin20.1.0 --target=riscv64-unknown-elf" (if I build them) or "--host=x86_64-apple-darwin17.7.0 --target=riscv64-unknown-elf" (a more sensible default for home-brew or the SiFive builds for distribution) with the host being irrelevant to this case.
Adding --enable-targets=all doesn't help.
It's not like that version of bfd or binptils can't read that very binary:
tmp/gdb/riscv-binutils-gdb/binutils/nm-new ../md0unix 08000f36 W ADC0_1_IRQn_handler 20005fd8 B BACK_COLOR 08000f36 W CAN0_EWMC_IRQn_handler 08000f36 W CAN0_RX0_IRQn_handler [ ... ]
the new objdump --disassemble easily groks that symbol table.
The SiFive-provided binary (and Homebrew of past) brilliantly read both sized of objects and recognize serial remote packets when coming from the SEGGER/Jlink/JLinkGDBServer -device GD32VF103CBT6 socket. (This is failing before packets are exchanged...I'm just offering than when it doesn't fail here, the auto-switching works really well.)
I'd like to help get this repaired in the Homebrew build, but I think this repository is probably the best intersection of such issues. Do any of you recognize this or have advice on how to debug it?
Thanx in advance, RJL