treewide: support i386-pc-elf target, make errors prettier #50562

oxij · 2018-11-18T08:29:07Z

This target used by coreboot and its payloads.

Ericson2314 · 2018-11-18T16:23:01Z

Do you actually want no libc or do you want newlib? @matthewbauer where did you newlib stuff go?

matthewbauer · 2018-11-18T20:05:32Z

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).

Ericson2314 · 2018-11-18T21:30:21Z

Oh yes, let's get rid of pc and just use unknown. pc was a stupid convenience with no benefit, just added in the 1990s because somebody thought unknown looked too scary.

Ericson2314 · 2018-11-18T21:36:23Z

lib/systems/inspect.nix

+    # 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; };


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.

That sounds good! If anything truly works on just i686 then just ask users to do stdenv.hostPlatform.parsed.cpu.name == "i686".

LLVM does http://llvm.org/doxygen/Triple_8cpp_source.html has i386 through i986, fwiw.

I think we should limit it to i386, i486, i586, and i686. The newer ones never really caught on.

matthewbauer · 2018-11-18T23:15:49Z

Another thing with libc = null, it should only build gcc once. Is that the case currently @Ericson2314

oxij · 2018-11-18T23:35:22Z

@Ericson2314

Do you actually want no libc or do you want newlib?

coreboot needs no libc, it's a BIOS.

Oh yes, let's get rid of pc and just use unknown.

The problem is that AFAIK you have to set the host platform to i386-pc-elf for coreboot to cross-compile. Sure, it can be parsed in nix as whatever, but the argument to the configure script must have the pc bit.

So I think we should have isx86_32 and isx86_64.

SGTM. Should I add those in this PR?

@matthewbauer

I think you should add an entry to examples.nix to provide an example config for this

I have the whole of coreboot as an example in the patch queue somewhere but it depends on some more changes to gcc I can't upstream yet (not cleaned up). And I have no other examples of this.

Perhaps this one will support some '90s CPUs while the i686 doesn't?

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.

Ericson2314 · 2018-11-19T01:30:08Z

coreboot needs no libc, it's a BIOS.

There exists many pure functions in libc, which newlib provides.

Is that the case currently @Ericson2314

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).

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.

SGTM. Should I add those in this PR?

Please do, and also remove isi386 and make isi686 = isx86_32. Maybe even add i486, i586, etc, so people get the point that the granularity is over the top.

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.

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.

matthewbauer · 2018-11-19T01:33:23Z

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?

Ericson2314 · 2018-11-19T18:28:48Z

@matthewbauer I disagree; I still think coreboot is asking with ridiculous specificity.

Ericson2314 · 2018-11-19T18:35:37Z

lib/systems/parse.nix

@@ -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


We can use version like arm.

matthewbauer · 2018-11-21T04:03:51Z

lib/systems/parse.nix

@@ -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; }; };


elf isn't a kernel - it's an abi

And barely an ABI, since that normally refers to the machine code itself not the container.

Ericson2314 · 2018-11-21T04:15:15Z

Maybe we should do this in steps so there's less to think about. We can get coreboot working in parallel.

oxij · 2018-11-21T07:10:24Z

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.

oxij · 2018-11-21T07:31:18Z

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.

nixos-discourse · 2018-11-21T21:59:04Z

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

goertzenator · 2018-11-22T15:28:36Z

Here a quick idea of what isx86_32 implementation looks like.

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 isx86_32.

Ericson2314 · 2019-01-18T22:23:52Z

Anything left here that isn't on master?

matthewbauer · 2019-01-18T22:31:05Z

I think getting rid of libcChooser would be nice... but otherwise I think this isn't needed anymore.

oxij · 2019-02-19T21:22:01Z

Yes, only libcChooser thing is left here. Let's close this, I'll make a separate PR for that later.

Ericson2314 · 2019-02-20T22:05:24Z

@oxij Thanks!

oxij requested review from Ericson2314, matthewbauer and nbp as code owners November 18, 2018 08:29

GrahamcOfBorg added 8.has: clean-up 10.rebuild-darwin: 0 10.rebuild-linux: 1-10 labels Nov 18, 2018

Ericson2314 reviewed Nov 18, 2018

View reviewed changes

Ericson2314 reviewed Nov 19, 2018

View reviewed changes

matthewbauer reviewed Nov 21, 2018

View reviewed changes

oxij closed this Feb 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

treewide: support i386-pc-elf target, make errors prettier #50562

treewide: support i386-pc-elf target, make errors prettier #50562

oxij commented Nov 18, 2018

Ericson2314 commented Nov 18, 2018

matthewbauer commented Nov 18, 2018

Ericson2314 commented Nov 18, 2018

Ericson2314 Nov 18, 2018

matthewbauer Nov 19, 2018

Ericson2314 Nov 20, 2018

matthewbauer Nov 21, 2018

matthewbauer commented Nov 18, 2018

oxij commented Nov 18, 2018

Ericson2314 commented Nov 19, 2018

matthewbauer commented Nov 19, 2018 •

edited

Loading

Ericson2314 commented Nov 19, 2018

Ericson2314 Nov 19, 2018

matthewbauer Nov 21, 2018

Ericson2314 Nov 21, 2018 •

edited

Loading

Ericson2314 commented Nov 21, 2018

oxij commented Nov 21, 2018 via email

oxij commented Nov 21, 2018 via email

nixos-discourse commented Nov 21, 2018

goertzenator commented Nov 22, 2018

Ericson2314 commented Jan 18, 2019

matthewbauer commented Jan 18, 2019

oxij commented Feb 19, 2019

Ericson2314 commented Feb 20, 2019

treewide: support i386-pc-elf target, make errors prettier #50562

treewide: support i386-pc-elf target, make errors prettier #50562

Conversation

oxij commented Nov 18, 2018

Ericson2314 commented Nov 18, 2018

matthewbauer commented Nov 18, 2018

Ericson2314 commented Nov 18, 2018

Ericson2314 Nov 18, 2018

Choose a reason for hiding this comment

matthewbauer Nov 19, 2018

Choose a reason for hiding this comment

Ericson2314 Nov 20, 2018

Choose a reason for hiding this comment

matthewbauer Nov 21, 2018

Choose a reason for hiding this comment

matthewbauer commented Nov 18, 2018

oxij commented Nov 18, 2018

Ericson2314 commented Nov 19, 2018

matthewbauer commented Nov 19, 2018 • edited Loading

Ericson2314 commented Nov 19, 2018

Ericson2314 Nov 19, 2018

Choose a reason for hiding this comment

matthewbauer Nov 21, 2018

Choose a reason for hiding this comment

Ericson2314 Nov 21, 2018 • edited Loading

Choose a reason for hiding this comment

Ericson2314 commented Nov 21, 2018

oxij commented Nov 21, 2018 via email

oxij commented Nov 21, 2018 via email

nixos-discourse commented Nov 21, 2018

goertzenator commented Nov 22, 2018

Ericson2314 commented Jan 18, 2019

matthewbauer commented Jan 18, 2019

oxij commented Feb 19, 2019

Ericson2314 commented Feb 20, 2019

matthewbauer commented Nov 19, 2018 •

edited

Loading

Ericson2314 Nov 21, 2018 •

edited

Loading