Discussion on x86_64-unknown-none-hermitkernel target
haraldh opened this issue · comments
Followup discussion for
@haraldh I thought a little bit about your request. The main issue is that our llvm target is also defined in the spec file (see https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_none_hermitkernel.rs#L14). This is used to define our kernel as standalone kernel (https://github.com/llvm/llvm-project/blob/e356027016c6365b3d8924f54c33e2c63d931492/llvm/include/llvm/MC/MCELFObjectWriter.h#L76-L77). In our case, we develop a library operating systems and everything is linked to one single boot image. Maybe it is currently working, but if I understand everything correctly, every part of the image should use the same OSABI. What do you think?
Originally posted by @stlankes in rust-lang/rust#89062 (comment)
So, with x86_64-unknown-none instead of x86_64-unknown-none-hermitkernel the resulting binary is still ELFOSABI_STANDALONE
❯ readelf -h target/x86_64-unknown-hermit/debug/rusty_demo
ELF Header:
[…]
OS/ABI: <unknown: ff>
❯ find target/ -name '*.a' -o -name '*.o' -print0 | xargs -0 readelf -h | grep -F 'OS/ABI' | sort -u
OS/ABI: UNIX - System V
OS/ABI: <unknown: ff>
Are you worried, that the linker would not want to link a ELFOSABI_NONE to a ELFOSABI_STANDALONE to produce a binary with ELFOSABI_STANDALONE ??
Yes, I am not sure if this is correct behavior and would work also with all linkers.
We could change the OSABI of the static library with elfedit. But this isn't part of corgo-binutils. An OS-independent version of elfedit will be great.
I don't want to introduce problems to your project... I just thought out loud on how to reduce targets with basically the same definitions.
Yes, I completely understand. I discuss this @mkroening. Maybe we find a good solution.
@haraldh The "none"-target for aarch64 doesn't support dynamic relocation (see https://github.com/hermitcore/rusty-hermit/runs/4747837810?check_suite_focus=true). Do you think that this feature could be enabled like in x86_64-unknown-none?
@haraldh The "none"-target for aarch64 doesn't support dynamic relocation (see https://github.com/hermitcore/rusty-hermit/runs/4747837810?check_suite_focus=true). Do you think that this feature could be enabled like in x86_64-unknown-none?
@stlankes sorry, I am not familiar with the state of the aarch64 linkers
@stlankes @mkroening We're about to proceed with proposing that x86_64-unknown-none be made a Tier 2 platform. One of the minor questions from the original Tier 3 addition was whether or not this target would suffice to replace the x86_64-unknown-none-hermitkernel target, to avoid a profusion of similar targets. Do you think that x86_64-unknown-none would suffice for your needs, allowing Rust to remove the x86_64-unknown-none-hermitkernel target?
Since we want to use our own llvm-target for now, we can't switch to x86_64-unknown-none. We should be able to maintain our target specification in this repository instead of the Rust repository though. I opened hermit-os/kernel#395 for that.
I can create PRs removing the hermitkernel targets from the Rust repository once hermit-os/kernel#395 is merged.
Out of curiosity, is the desire not to use x86_64-unknown-none due to some deficiency in the target? If so, then it might make sense for us to try to address it before moving it to Tier 2.
The only relevant difference between the targets is "llvm-target": "x86_64-unknown-hermit" as opposed to "llvm-target": "x86_64-unknown-none-elf". The other differences can be removed on our side in the future. Functionally, x86_64-unknown-none works fine for us.
The effect of our llvm-target is some magic number shenanigans in the resulting library archive. This could be achieved as well via manual post-processing in the future (using xtasks introduced in hermit-os/kernel#378), as moving to a higher tier target might be worth the effort.
This is not a deficiency in x86_64-unknown-none, as this is hermit-specific, and should not require any change in x86_64-unknown-none.
Great, thanks for the info!
I opened rust-lang/rust#95299.