I compile a program that uses floating point registers. It core dumps, as expected. I pull the core file back to my dev box, and use the cross gdb riscv64-unknown-linux-gnu-gdb to analyze the core file. The command info all-registers or info float says the fp registers are . Using cross objdump, I don’t see any ELF notes with a type of NT_FPREGSET.
Where did the fp registers get saved in the core file, and how do I see them with cross-gdb?
I haven’t done the fp-reg core file support for gdb yet. One of many things on my to do list. I believe the fp regs are in the .reg2 section, though I don’t know how the kernel puts them there. Anyways, it should be fairly easy for gdb to load them from there. I hacked up a patch that appears to work, but needs some proper testing before I can submit it upstream.
There doesn’t seem to be a way to attach files here, so I put it in a riscv-binutils-gdb issue.
You can use native gdb if you build a new kernel with the gdb ptrace support (4.20 or later), and build a new gdb from FSF top of tree, but that is still a little tricky as not all of the drivers needed for the HiFive Unleashed are upstream yet. If you really want to try this, you can find info about the drivers you need here
Just ignore the stuff about the Microsemi expansion board and look at the list of drivers he had to add to 4.19 to make it work. You need the same list for 4.20 unless maybe some of them are already in 4.20.
And oh, if you want to do serious work on a HiFive Unleashed, you really should consider getting one of the distros: Debian, Fedora, OpenSuse, OpenEmbeddded/Yocto, FreeBSD, etc. The system that ships with the board is a simple buildroot system with a lot of limitations.
I kind of understand how gdbserver pushes target description xml back to gdb, and then presumably can also push binary(?) data back to gdb to be parsed/printed by gdb, as driven by the xml.
Is there a mechanism wherein a core file can contain the same format binary data, wrapped in a well named ELF NOTE, and then have gdb get the binary data from the elf note, and consume it appropriately?
I’m trying to extend openOCD so it can write a compliant core file, complete with implementation specific registers described by xml.
I’m a gcc developer doing gdb work because I got tired of waiting for someone else to do it. I don’t have a good understanding of how this stuff works. I’m learning as I go along. But as far as I know, the linux kernel puts the integer regs in the .reg section and the FP regs in the .reg2 section, and the only other info gdb has is the section sizes, from which we can compute whether these are 32-bit registers or 64-bit registers. I looked at half a dozen linux targets and they all work this way. This is of course linux specific. It would be possible to have core file support for other operating systems where the core file is structured differently. But if it is linux you care about, then you should be following the core file format used by the linux kernel.
I don’t know anything about note sections in a core file. I haven’t needed to learn that yet.
I’m doing the gdb work on a 64-bit Unleashed, so that is the only thing I’ve tested, and probably the only linux target it works for. I’ve tried to add in 32-bit support where appropriate, but I haven’t been able to test any of it. I haven’t tried to do anything interesting in the core file support. But as mentioned above, we can check the section sizes, and do appropriate things from that, e.g. treat the int regs as 32-bit or 64-bit based on section size, and likewise for the FP regs. That solves part of the problem. If you need something more complicated then I probably can’t help much, as I would need a lot of time to learn more about how gdb and core files work.