| Summary: | sys-devel/gdb-8.3: bfd requires flen 8, but target has flen 0 on riscv64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marcus Comstedt <marcus> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | riscv | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Marcus Comstedt
2019-07-06 20:49:44 UTC
Note: This is not a regression per se from 8.2.1, which did not support the run command at all. However, gdb from Jim Wilson's github branch "jimw-riscv-linux-gdb" works correctly with breakpoints on the same system. Performing a bisect on upstreams git, I found that the breakage was introduced by 90af06793e gdb/riscv: Improve logic for when h/w float abi should be used The code looking at the ELF correctly determines flen=8 from the ELF flags Flags: 0x5, RVC, double-float ABI and initially this also translates into a "feature_fpu" with 64-bit registers. But upon executing the "run" command "feature_fpu" suddenly becomes NULL, causing flen to be set to 0, and triggering the "but target has flen 0" error. I assume this means that only the lp64d ABI is affected by the bug, not lp64. Will investigate further when I'm less sleepy... Ok, I figured it out. riscv-linux-nat.c sets features.flen to 0 because ptrace(PTRACE_GETREGSET, tid, NT_FPREGSET) gives an "Invalid argument". This happens on any kernel earlier than 4.20, since the required support was missing in ptrace. (I'm on 4.19 because later kernels did not support the HiFive Unleashed builtin peripherals. I notice that 5.2 was just released, so hopefully I can finally upgrade now... :-) Before 90af06793e the program could still be debugged, just without FPU debugging (which was fine if the program was compiled for lp64d but didn't actually use floating point). But now gdb bombs out. While this is less than perfect, at least there should be two workarounds: 1) Upgrade to 4.20 or later (5.x in practice, since 4.20 is EOL) or 2) switch profile to lp64 ABI Closing as obsolete as this gdb version is not in tree and newer kernel was a good enough workaround. |
