[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- Using readelf -wr to look at the debug_aranges section, I see entries like Length: 44 Version: 2 Offset into .debug_info: 0x987 Pointer Size: 4 Segment Size: 0 AddressLength 20400132 0002 20400134 003a An address/length entry of 0/0 is supposed to mark the end of the list, but here we have one at the beginning. This is confusing elfutils which is trying to move byte by byte through the aranges section. libdw/dwarf_aranges.c has /* Two zero values mark the end. */ if (range_address == 0 && range_length == 0) break; and then assumes that the next entry is immediately following, which it isn't, and it ends up reading garbage. binutils seems to be using the length field to find the last entry. And readelf is ignoring the 0/0 end of list rule so that we can see the invalid entries. There are a lot of aranges that have 0/0 entries not at the end of the list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805
--- Comment #3 from Jim Wilson ---
My first thought was linkonce/comdat, but that is used by C++ and would have
shown up before. So that leaves -gc-sections. I can reproduce with a simple
example.
rohan:2010$ cat tmp.c
extern int sub1 (int);
extern int sub2 (int);
extern int sub3 (int);
extern int sub4 (int);
int main (void) { return sub2 (sub4 (0)); }
rohan:2011$ cat tmp2.c
int sub1 (int i) {return i + 10; }
int sub2 (int i) {return i + 20; }
int sub3 (int i) {return i - 10; }
int sub4 (int i) {return i - 20; }
rohan:2012$ riscv32-unknown-elf-gcc -O2 tmp.c tmp2.c -ffunction-sections
-Wl,-gc-sections -g
rohan:2013$ readelf -wr a.out
Contents of the .debug_aranges section:
Length: 28
Version: 2
Offset into .debug_info: 0x0
Pointer Size: 4
Segment Size: 0
AddressLength
00010074 000e
Length: 52
Version: 2
Offset into .debug_info: 0x7c
Pointer Size: 4
Segment Size: 0
AddressLength
00010114 0004
00010118 0004
rohan:2014$
I get the same result with an x86_64-linux compiler. And I get the same result
with -gdwarf-5.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 --- Comment #4 from Jim Wilson --- Actually I just noticed with the x86_64-linux compiler I'm getting addresses of 0 but lengths of 4 which would be OK. Length: 92 Version: 2 Offset into .debug_info: 0x8c Pointer Size: 8 Segment Size: 0 AddressLength 0004 0620 0004 0004 0630 0004 This is an Ubuntu 18.04 gcc-7.6 toolchain. Not clear why it is different. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #3 from Jim Wilson --- I'm not aware of any supported lp64 linux systems, so I don't know why the patch is needed, and I am unable to test it. It does look mostly reasonable. The riscv_init.c change isn't quite correct as we have 3 64-bit ABIs. lp64d is 64-bit FP registers, lp64f is 32-bit FP registers, and lp64 is no FP registers. So we actually need a check for the lp64 ABI instead of assuming that !lp64d is lp64. Also the "lp64i" should be "lp64" to be consistent with the ABI naming scheme. I would suspect other changes are required for full lp64 support. riscv_abi_cfi references FP registers unconditionally. riscv_register_info references FP registers unconditionally. The lp64 and lp64f support is incomplete because I've never had access to a system where I can do the necessary work. Similarly, the ilp32, ilp32f, and ilp64d support is also incomplete as I don't have access to any system I can use to develop them. All RISC-V linux desktop distros are lp64d. I think the linux kernel lacks support for ilp32f and lp64f so those may be impossible to build at present. There are some embedded linux distros that use the 32-bit ABIs, and/or that use soft-float ABIs, but SiFive doesn't support those. So I'd have to build an entire linux distro from scratch and boot on qemu to set up an environment just to do an elfutils port, and I haven't been willing to do that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #5 from Jim Wilson --- I hadn't thought about the kernel. It is compiled LP64 and with the FP extensions disabled, to avoid accidentally using FP registers. It does save/restore FP registers in the context switching code, but otherwise doesn't use FP registers, so that we don't have to save/restore FP registers in system calls. If there are no FP types in the kernel then LP64D will behave identically to LP64. But if you have a testsuite that checks all features, then we would have to implement LP64 correctly, and your patch is a step in the right direction. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #8 from Jim Wilson --- Calling convention docs: https://github.com/riscv-non-isa/riscv-elf-psabi-doc Recently converted from markdown to asciidoc. The releases link on the right contains pdf files which are likely the easiest way to read this. Yes, any float larger than the FP regs is passed in the integer regs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #9 from Jim Wilson --- The patch looks OK to me. In the old code, for float and double (not complex) we call pass_in_fpr_lp64d because it returns the same result as pass_in_fpr_lp64f and not worth an extra check for that. In the new code, float and double are now handled separately, and the call to pass_in_fpr_lp64d for the float case looks a little funny but it will give the right result. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #11 from Jim Wilson --- Userspace is lp64d. The kernel is lp64. You can't create an lp64 binary because there are no lp64 start files or libraries. The kernel can be linked because it doesn't require any start files or libraries. The riscv backend is using the ELF header flags to determine if a binary is lp64 or lp64d, so if you can't create an lp64 binary you can't run an lp64 test. Similarly, you also can't construct and run lp64f, ilp32, ilp32f, or ilp32d ABI tests for the same reason. The difference between lp64 and lp64d is that FP values are passed in integer regs in the first and FP regs in the second. If you aren't testing FP values, then you aren't properly testing the lp64 ABI. Though given that the kernel is compiled soft-float, such testing would be sufficient for using elfutils with an lp64 kernel, but not for a lp64 user space. The best way to test the lp64 ABI support is to build an entire linux system from scratch using an lp64 userspace. You can then natively test the lp64 support. Likewise for lp64f, ilp32, ilp32f, and ilp32d. That is outside the scope of this bug report. -- You are receiving this mail because: You are on the CC list for the bug.
