Add x86_64-linux-kernel target

[alex]

This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.

I wasn't totally sure about what the best name for this was.

There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace.

r? @joshtriplett

[alex]

The failing mingw-check build doesn't seem related at all.

[rust-highfive]

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-09-01T02:50:26.2561895Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-09-01T02:50:26.8027751Z ##[command]git config gc.auto 0
2019-09-01T02:50:26.8032716Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-09-01T02:50:26.8037694Z ##[command]git config --get-all http.proxy
2019-09-01T02:50:26.8040304Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/64051/merge:refs/remotes/pull/64051/merge

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[joshtriplett]

Looks great to me!

@bors r+

[bors]

📌 Commit 5e933b4 has been approved by joshtriplett

[alex]

@joshtriplett Thanks much! If we wanted to move this to tier 2, providing pre-compiled libcore, what's involved in doing that? Just hacking on the build scripts?

[bors]

⌛ Testing commit 5e933b4 with merge 3d879bbc55e6515a201fac7a78a2dbeee5f38a9f...

[bors]

💔 Test failed - checks-azure

[rust-highfive]

The job x86_64-gnu-aux of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[alex]

Test appears to have failed with:

 Downloading crates ...
  Downloaded lazy_static v0.2.5
  Downloaded conduit-mime-types v0.7.3
error: failed to download from `https://crates.io/api/v1/crates/log/0.3.7/download`

Caused by:
  [35] SSL connect error (error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure)
thread 'main' panicked at 'tests failed for https://github.com/iron/iron', src/tools/cargotest/main.rs:86:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

which seems unrelated?

[joshtriplett]

Yeah, that does look entirely unrelated.

@bors retry

[bors]

⌛ Testing commit 5e933b4 with merge 9b0a099c274d69bd9cb1cbbd7a967fe28c3a77d1...

[mati865]

Is there a way we can control the use of PIE at build time using stable Rust options?

AFAIK Rust libs have to be compiled with the same PIE config as the resulting binary making xargo necessary.

[rust-highfive]

The job x86_64-gnu-aux of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[bors]

💔 Test failed - checks-azure

[alex]

Another SSL error.

[alex]

@joshtriplett I think this can safely be retry'd

[joshtriplett]

@bors retry

[Ericson2314]

I was pointed to #74247, a better place to bring this up.

---

Sorry I'm late to the party, but is x86_64-linux-kernel something made up for Linux with Rust, or a preexisting convention? If it is new, I would strongly prefer that it be changed.

The triples/configs/whatever are a mess, but so far mentioning some OS has meant "I am running on that OS" i.e. "I have a interface[1] for communicating with that kernel and I am one of its processes". But Kernel code doesn't talk to the kernel via syscalls, and thus violates that assumption.

Perhaps #[cfg(target_os = "linux")] has been patched to be false for this, but other tools besides rust also deal with this triples, and this would require a new special case everywhere to handle, which is a big maintenance burden.

Something like x86_64-unknown-linuxkernel or even x86_64-unknown-none (the kernel is a baremetal program, after all) would be far, far preferable.

---

[1] Whether the direct syscall ABI is stable, like Linux or a canonical libc is, like FreeBSD, is a separate distinction to the point I'm making. Regardless of what's stabilized internal kernel interfaces are very different than the interfaces for hosted processes.

[alex]

It was invented for Rust. I don't have a strong opinion on the correct convention, and I'm more than happy to do whatever the Rust devs think is best.

…

On Sun, Oct 11, 2020 at 4:27 PM John Ericson ***@***.***> wrote: Sorry I'm late to the party, but is x86_64-linux-kernel something made up for Linux with Rust, or a preexisting convention? If it is new, I would *strongly* prefer that it be changed. The triples/configs/whatever are a mess, but so far mentioning some OS has meant "I am running on that OS" i.e. "I have a interface[1] for communicating with that kernel and I am one of its processes". But Kernel code does talk to the kernel via syscalls, and thus *violates* that assumption. Perhaps #[cfg(target_os = "linux")] has been patched to be false for this, but other tools besides rust also deal with this triples, and this would require a new special case everywhere to handle, which is a big maintenance burden. Something like x86_64-unknown-linuxkernel or even x86_64-unknown-none (the kernel is a baremetal program, after all) would be far, far preferable. [1] Whether the direct syscall ABI is stable, like Linux or a canonical libc is, like FreeBSD, is a separate distinction to the point I'm making. Regardless of what's stabilized internal kernel interfaces are very different than the interfaces for hosted processes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64051 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBE5B3OTVEI7YKEWPVLSKIIK3ANCNFSM4ISVMTRA> .

-- All that is necessary for evil to succeed is for good people to do nothing.