Page MenuHomeFreeBSD

ld.bfd requires an explicit emulation for MIPS for ld -r.
ClosedPublic

Authored by jhb on Jul 19 2020, 8:44 PM.
Tags
None
Referenced Files
F102872766: D25728.id.diff
Mon, Nov 18, 6:48 AM
Unknown Object (File)
Tue, Nov 5, 10:09 AM
Unknown Object (File)
Sun, Oct 20, 10:10 AM
Unknown Object (File)
Oct 7 2024, 3:19 AM
Unknown Object (File)
Oct 2 2024, 6:00 AM
Unknown Object (File)
Sep 27 2024, 1:11 AM
Unknown Object (File)
Sep 12 2024, 7:50 PM
Unknown Object (File)
Sep 8 2024, 12:03 PM
Subscribers

Details

Test Plan
  • build mips64 with mips-gcc6 toolchain (32-bit mips builds fine)

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 32418
Build 29895: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Jul 19 2020, 8:44 PM
jhb created this revision.
  • Fixup to MIPS ld flags.
This revision was not accepted when it landed; it landed in state Needs Review.Aug 4 2020, 6:24 PM
This revision was automatically updated to reflect the committed changes.

Hmm, I guess it is what it is. I presume we don't need ld emulation anywhere else?

MIPS is kind of special as we use the same toolchain for multiple ABIs whereas for most other platforms we use a dedicated toolchain for each ABI where the default ABI matches. lld is a bit better about this as it will infer the emulation from the object files. If powerpc were fixed to use a shared GCC toolchain for powerpc and powerpc64 it would probably need this, similar to if we had a shared amd64/i386 GCC.

@jhb thanks for the info, although I meant are there other places we're passing -m <emulation> (which presumably need or already have something similar) rather than are there other archs that would need it.

@jhb thanks for the info, although I meant are there other places we're passing -m <emulation> (which presumably need or already have something similar) rather than are there other archs that would need it.

The kernel uses an explicit LD for the link of the kernel itself and we have LD_EMULATION_<machine_arch> helper variables in kern.post.mk IIRC to deal with that. I think we also use those for some of the firmware blob stuff. We mostly avoid explicit LD though (and arguably we should avoid it whenever possible, though ld -r is a case we can't use the compiler driver to do)