-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
LLVM target's OS/ABI is lost #97535
Comments
Hmm, the Unfortunately currently I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs? |
Ah, yes, I think there are three possibilities:
For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think?
Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using |
Here's how LLVM determines what OSABI to use: https://github.com/llvm/llvm-project/blob/18c1ee04de448a6a4babbaf8e5ba42866339b466/llvm/include/llvm/MC/MCELFObjectWriter.h. We could look at The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc @petrochenkov, what's your take on this issue? |
object-rs has only recently been taught to set |
All right. Thanks for the quick feedback. I'll cook something up in the coming days. |
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-low |
I opened #97633, but first the necessary changes in |
Session object: Set OS/ABI Closes rust-lang#97535. This depends on * gimli-rs/object#438 This adapts LLVM's behavior of [`MCELFObjectTargetWriter::getOSABI`](https://github.com/llvm/llvm-project/blob/8c8a2679a20f621994fa904bcfc68775e7345edc/llvm/include/llvm/MC/MCELFObjectWriter.h#L72-L86).
When compiling for
x86_64-unknown-hermit
, the resulting binaries should have the OS/ABI (EI_OSABI
) field in the ELF header set to Standalone (0xff
) as per thex86_64-unknown-hermit
LLVM target, which it did beforenightly-2022-04-26
. Now, it is set to "UNIX - System V", which I only tested on Linux.git-bisect
identified the introduction of synthetic object files for exported symbols 773f533 from #95604 to have changed this:I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI.
@nbdd0121, do you have any insight?
Related: hermit-os/hermit-rs#300
The text was updated successfully, but these errors were encountered: