treewide: support i386-pc-elf target, make errors prettier #50562
Conversation
This target used by coreboot and its payloads.
|
Do you actually want no libc or do you want newlib? @matthewbauer where did you newlib stuff go? |
|
This is probably okay! I think you should add an entry to examples.nix to provide an example config for this. Something like "pc-embedded". I think the ARM toolchains always come with newlib - but it might not be common with this toolchain? Better to get as close as we can to what is found in the wild. There's really no standardization for these things. But maybe we can make some attempts at standardizing things. To be honest, I was hoping we could avoid this one just because it uses i386 which could complicate some logic (search for isi686 in Nixpkgs). Maybe having this will improve the situation though. I don't really understand the difference between this and i686-none-elf. Perhaps this one will support some '90s CPUs while the i686 doesn't? I would prefer to leave pc off here as that's not really a vendor. It is also kind of confusing whether "elf" refers to the ABI or the OS (in i686-none-elf: cpu=i686, vendor=unknown, os=none, abi=elf). |
|
Oh yes, let's get rid of |
| # NOTE: normal stuff should use i686, this type is purely for | ||
| # "i386-pc-elf" target (e.g. coreboot and its payloads) | ||
| isi386 = { cpu = cpuTypes.i386; }; | ||
|
|
||
| isi686 = { cpu = cpuTypes.i686; }; |
There was a problem hiding this comment.
So I think we should have isx86_32 and isx86_64, with isi686 as an alias for isx86_32, perhaps to be deprecated. This matches what we do for arm. It also avoids a situation where we falsely say i386 isn't i686, which ignores subtyping / compatibility.
There was a problem hiding this comment.
That sounds good! If anything truly works on just i686 then just ask users to do stdenv.hostPlatform.parsed.cpu.name == "i686".
There was a problem hiding this comment.
LLVM does http://llvm.org/doxygen/Triple_8cpp_source.html has i386 through i986, fwiw.
There was a problem hiding this comment.
I think we should limit it to i386, i486, i586, and i686. The newer ones never really caught on.
|
Another thing with libc = null, it should only build gcc once. Is that the case currently @Ericson2314 |
The problem is that AFAIK you have to set the host platform to
SGTM. Should I add those in this PR?
I have the whole of
AFAIK i386 in this instance is a 133tspeak for "real mode". I.e. the most basic set of opcodes that all x86 CPUs should be able to run just after the reset. |
There exists many pure functions in libc, which newlib provides.
It didn't look like it. TBH this is part of the reason why I hop we can get away with the newlib case. it should be basically free at runtime when not used (since static linking).
We can lie to coreboot or patch it.
Please do, and also remove
I doubt its anything that specific. I bios would get a trip though the whole 1980s in different modes. I think this is just some arbitrary historical choice on coreboot's part. |
|
Yeah sounds fine to just follow coreboot in this respect for compatibility, though. I would want to verify this only uses 1 GCC stage. Is that correct? |
|
@matthewbauer I disagree; I still think coreboot is asking with ridiculous specificity. |
| @@ -82,6 +82,7 @@ rec { | |||
| aarch64 = { bits = 64; significantByte = littleEndian; family = "arm"; version = "8"; }; | |||
| aarch64_be = { bits = 64; significantByte = bigEndian; family = "arm"; version = "8"; }; | |||
|
|
|||
| i386 = { bits = 32; significantByte = littleEndian; family = "x86"; }; # see inspect.nix | |||
There was a problem hiding this comment.
We can use version like arm.
| @@ -174,14 +176,17 @@ rec { | |||
| types.kernel = enum (attrValues kernels); | |||
|
|
|||
| kernels = with execFormats; with kernelFamilies; setTypes types.openKernel { | |||
| # kernel-less targets | |||
| elf = { execFormat = elf; families = { inherit none; }; }; | |||
There was a problem hiding this comment.
elf isn't a kernel - it's an abi
There was a problem hiding this comment.
And barely an ABI, since that normally refers to the machine code itself not the container.
|
Maybe we should do this in steps so there's less to think about. We can get coreboot working in parallel. |
|
Well, feel to do whatever is right, then. I'm not possessive of the code.
Note however, that
> The problem is that AFAIK you have to set the host platform to i386-pc-elf for coreboot to cross-compile.
We can lie to coreboot or patch it.
you will have to patch a lot of things then, "*-pc-*" is used not just by coreboot but almost all the bare-hardware things, and it is the standard thing for `config.sub` script. Which you can easily see for yourself. Do
```
$ ls /nix/store/*-source/config.sub
```
and read through several of those files.
Running any one of them with the subject arch gives it back
```
$ /nix/store/<something>/config.sub "i386-pc-elf"
i386-pc-elf
```
which means that "i386-pc-elf" is a canonical value, i.e. it doesn't reduce to anything else (i.e. you can't just stick "unknown" there, "unknown" is a different canonical value).
`config.sub` parses things into `basic_machine` and `os` (and "i386-pc" is the "basic_machine" here) so, in some sense, the actual problem with supporting that in nixpkgs is that the lib tries to parse out more structure (like `kernel`) than there is.
Note that I'm not saying that reimplementing `config.sub` in nix would be a good idea (it's probably not, there's a bunch of outdated stuff there we will probably never support), I'm just saying that supporting canonical values `config.sub` produces is, as that will significantly reduce (if not eliminate) required patching.
E.g. by applying the patch in question I want able to build coreboot without any changes.
|
|
Btw, as to why vendor part ("pc") can be significant: consider modern game consoles, most of them are x86, but they are not "pc" in the sense that they use a different boot sequence from the original IBM PC, which starts in the 16/32 bit real mode and uses some funny IO ports to switch to the real mode.
For x86, AFAIK, this doesn't really mean much for the compiler since CPU and north bridge are married to each other and code with no funny segmentation will work in all the modes on x86. But, clearly, there's code assembler can emit for real mode that it can't emit for protected (and vice versa), so there's a difference, it's just on x86 doing such things is not in fashionable. But, apparently, on other architectures the `vendor` part might actually significantly modify the opcodes assembler needs to emit and CPU need to execute to run the machine properly.
In short, you can't just disregard it unless you plan to never ever support something like that with nix cross-compiling infra.
|
|
This pull request has been mentioned on Nix community. There might be relevant details there: https://discourse.nixos.org/t/i586-cross-compiling-ambiguous-i686-use/1482/6 |
|
Here a quick idea of what I'm still trying to get all this working, but it seemed salient to share it now. I'm also working on a RFC for |
|
Anything left here that isn't on master? |
|
I think getting rid of libcChooser would be nice... but otherwise I think this isn't needed anymore. |
|
Yes, only |
|
@oxij Thanks! |
This target used by coreboot and its payloads.
/cc @Ericson2314