When the linker doesn't have this feature, add -mno-relax to CFLAGS
on RISC-V.
Define the feature for ld.bfd, but not lld. When lld gains relaxation
support in a newer version, we can enable it for those versions of lld
in bsd.linker.mk.
Details
Details
- Reviewers
br mhorne jrtc27 - Commits
- rS355428: Add a new "riscv-relaxations" linker feature.
- build and booted world + kernel built with clang and lld
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| share/mk/bsd.cpu.mk | ||
|---|---|---|
| 380 ↗ | (On Diff #65185) | Does this also need to go in AFLAGS? I see it's only being set for MIPS's endianness/ABI flags, when a bunch of other flags in here would seem appropriate, so perhaps it's not needed and CFLAGS is passed through, but however the assembler is invoked by the build system, -mno-relax must be present when assembling too. |
| share/mk/bsd.cpu.mk | ||
|---|---|---|
| 380 ↗ | (On Diff #65185) | In general FreeBSD's build no longer uses as directly but always uses the compiler driver for assembly files, so AFLAGS isn't really used. There is an ACFLAGS for assembly-specific flags to pass to the compiler driver, but that is passed in addition to CFLAGS. I know that GCC requires the extra -Wa that you used, but I don't really expect folks to use lld with GCC on FreeBSD, more to either use GCC + bfd or use clang + lld. |
| share/mk/bsd.cpu.mk | ||
|---|---|---|
| 380 ↗ | (On Diff #65185) | Yes, I was not commenting on the -Wa,-mno-relax requirement for GCC+LLD, which is a highly unusual combination. So long as the compiler is used as the driver then I'm happy. |
Comment Actions
There isn't really a precedent for arch-specific linker features, but I don't think it's an issue. Do you know how long it might be before we see support for relaxations in lld? If it's not long, could we not just check for lld directly instead of using a linker feature?
Comment Actions
I don't know of anyone actively working on it, so it could well be a while, but equally someone could turn up tomorrow out of nowhere with a patch. I also don't know how amenable LLD is to linker relaxation, as the data structures may not like the idea that input sections can change in size (and instructions can move within them, with their associated relocations, as a result). But I suspect it's unlikely to be happening within a year.