-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[LLD] Adding a modern target-selection flag to the drivers #97124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@llvm/issue-subscribers-lld-elf Author: John Ericson (Ericson2314)
LLD's frontends are currently very faithful to the linkers they are based on. But that means the target-selection mechanisms they have are rather underpowered. I think would be good to have modern flags that would allow us to set the `EM_*` choice, `ELFOSABI_*` choice, and `ELFKind` independently (for valid combinations)
A good use for this would be better handling of the "OSABI" field. For example: ProblemsFreeBSD existing hacksllvm-project/lld/ELF/Driver.cpp Lines 174 to 177 in 9572388
is an ad-hoc hack for FreeBSD. The corresponding code in Clang to use it is even uglier: llvm-project/clang/lib/Driver/ToolChains/FreeBSD.cpp Lines 174 to 218 in 9572388
If Clang could use "regular" code to transform the CPU into a OpenBSD has similar needsAs discussed in #92675, we ought to have CI for OpenBSD, but OpenBSD has some outstanding downstream changes that need to be upstreamed before upstream-tool-produced binaries will work, and many of those changes today assume OpenBSD->OpenBSD native compilation and so are unfit to upstream as is #97122 is the first such patch I've rebased. This is a somewhat borderline case, as there is already blanket handling to SolutionsProposal A:
|
We can do something more lightweight. Does #97144 work for you? While OpenBSD has proposed many interesting ideas for security hardening, I am deeply concerned of its development practices and I hope that there is special support to merge |
Not in particular, I think. The main distinction, probably somewhat similar to the target OS of an ELF object, is about whether it targets the mingw or MSVC ABI. And we already handle that in LLD, by using two separate entry points (
I don't think it's needed, but you could invent a But as said above, I don't see a direct need for it at all. |
Yes, I think it does! Assuming Clang already sets that or can easily be made to do so, which I think is true. @mstorsjo Thanks for the feedback. It's nice that @MaskRay's solution sidesteps the need for a new flag. |
Closing because #97144 does work for me :) |
LLD's frontends are currently very faithful to the linkers they are based on. But that means the target-selection mechanisms they have are rather underpowered. I think would be good to have modern flags that would allow us to set the
EM_*
choice,ELFOSABI_*
choice, andELFKind
independently (for valid combinations)A good use for this would be better handling of the "OSABI" field. For example:
Problems
FreeBSD existing hacks
llvm-project/lld/ELF/Driver.cpp
Lines 174 to 177 in 9572388
is an ad-hoc hack for FreeBSD. The corresponding code in Clang to use it is even uglier:
llvm-project/clang/lib/Driver/ToolChains/FreeBSD.cpp
Lines 174 to 218 in 9572388
If Clang could use "regular" code to transform the CPU into a
-m
flag, and then separately tell LLD that theELFOSABI_*
isELFOSABI_FREEBSD
, that would be much cleaner.OpenBSD has similar needs
As discussed in #92675, we ought to have CI for OpenBSD, but OpenBSD has some outstanding downstream changes that need to be upstreamed before upstream-tool-produced binaries will work, and many of those changes today assume OpenBSD->OpenBSD native compilation and so are unfit to upstream as is
#97122 is the first such patch I've rebased. This is a somewhat borderline case, as there is already blanket handling to
.openbsd.random
regardless of theELFOSABI_*
in use. Still, "stealing names" from all ELF usages of LLD doesn't seem very elegant, even if the.openbsd.random
case is grandfathered in --- I much rather start requiringELFOSABI_OPENBSD
with the.openbsd.random
case deprecated with a warning. That said, if doing this would require a_obsd
hack like FreeBSD's_fbsd
, I can't help but think the medicine is as almost as bad is the disease.Solutions
Proposal A:
--target
flagAdd a flag for "regular" LLVM triples --- like Clang's
--target
or LLVM's-mtriple
--- so we have more expressive power. Those triples should be mostly possible to map to the choices above, and-m
flags could still be used to fill in the gaps.Advantages:
--target
argument as-is and hope for the bestDisadvantages:
LLVM triples can both say to much and too little
Proposal B: New greenfield flags
Add multiple new flags for specifying the these parts independently. Certainly
ELFOSABI_
needs one.-m
does theEM_
andELFKind
residual alright, perhaps, or perhaps they get fresh new flags too.Advantages: No syntax vs semantics mismatch / friction / corner cases.
Disadvantage: Greenfield new flags for other tooling to have to learn about.
CC @brad0 because OpenBSD
C @mstorsjo because I am curious if Windows stuff has similar needs / not sure what to do about
lld-link
(clang-cl
takes--target
and many other GNU-style flags, butlld-link
only takes/flag
MS-style-flags)The text was updated successfully, but these errors were encountered: