Failed to build glibc for riscv64 about riscv-binutils-gdb HOT 2 CLOSED

Unless you have a strong reason to use the "riscv-next" branch, I'd recommend using the "riscv-binutils-2.28" branch. That is based on the stable binutils 2.28 release branch, which is a bit more suitable for distributions. We maintain this branch with all the RISC-V patches that make sense (which we also submit upstream once they're ready). There's a similar release branch for GCC, and there will be one for Linux and glibc once they've released upstream.

I'm going to leave this open, as it's probably a real bug.

from riscv-binutils-gdb.

Reproduced, and verified that this is fixed by issue #84. So closing.

There is a misunderstanding here about address sizes. Dwarf makes a distinction between program addresses whose size is determined by the ABI, and dwarf internal references, which are section relative offsets, fixed in size at 32-bits or 64-bits. GCC emits 32-bit dwarf for all targets except IBM AIX which chose to standardize on 64-bit dwarf for 64-bit ABIs. There is no need to move from 32-bit dwarf to 64-bti dwarf unless you have a single dwarf section which exceeds 4GB in size. Since dwarf is split across multiple sections, you would need about 8GB of dwarf info total before 64-bit dwarf becomes necessary.
Also, since 64-bit dwarf is larger than 32-bit dwarf, it should not be used unless you actually require it. So, since we have 32-bit dwarf here with a lp64 ABI, it is still only a 32-bit reloc fix that we need, which is what is in issue #84.

This does bring up an interesting point though. If a new reloc had to be added to the ABI to make 32-bit dwarf work correctly, then we probably need a new reloc to make 64-bit dwarf work correctly too. We may want to fix the ABI long before we actually need 64-bit dwarf. So this should be checked, but this should be a different issue that the one reported here.

from riscv-binutils-gdb.