change rustc-abi in custom targets to x86-softfloat

[n0toose]

Summary of the PR

This is a direct port of the Tom Dohrmann's PR:
rust-osdev/bootloader#492

Which, in turn, "fixes a nightly breakage introduced by": rust-lang/rust#136146

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[n0toose]

Do keep in mind that this change was applied "blindly" - haven't gotten around to testing this with an actual image yet.

[epilys]

@n0toose Cool, thanks! I don't remember if I've ever tried to test the crate on x86 tbh; if you have something I can replicate it to verify it works, it'd be helpful.

[n0toose]

if you have something I can replicate it to verify it works, it'd be helpful.

I could try doing so manually and provide instructions, but I'm not sure how that would scale to, say, a CI test suite (which would be the more sustainable approach). Only approach I can come up with is booting a prebuilt .qcow2 with Xen (and the relevant QEMU configs), building a test image and making it visible to the VM using virtiofs and then checking if the run is successful within the VM.

[epilys]

Check #12 which adds a test in the CI for aarch64 (which I should merge btw...) for how to do a simple smoke test that it boots and works, by writing to the hypervisor console with a hypercall.

[n0toose]

Check #12 which adds a test in the CI for aarch64 (which I should merge btw...) for how to do a simple smoke test that it boots and works, by writing to the hypervisor console with a hypercall.

Thanks, I actually did take a look but forgot about it - the question I had when I originally took a look is "should I expect a huge fundamental difference when attempting to emulate an HVM image vs. a PV image" configuration-wise?

Pardon if this comes across as trivial, but I am tinkering around and don't possess deep knowledge of the subject (not yet, anyway :D).

[epilys]

Configuration in Xen or otherwise?

Generally the difference in practice is what device drivers your kernel is using. Linux for example has specific drivers for Xen PV devices.

[n0toose]

Configuration in Xen or otherwise?

Generally the difference in practice is what device drivers your kernel is using. Linux for example has specific drivers for Xen PV devices.

I'd say Xen. Anyway, thanks for the tips - I don't know how long it will take me to find the time to try it out.

[epilys]

Note that oxerun is a bare metal kernel, and neither the examples or the smoke test CI PR do anything other than performing hypercalls- no devices involved.

The way I debugged/developed stuff with the aarch64 version was

1. compile and run the oxerun unikernel directly under qemu with direct kernel boot (without Xen). Use qemu's gdbstub to verify execution reaches the main function. Hypercalls should fail since there's no hypervisor, but at least MMU and interrupt/exceptions setup has worked for execution to have reached main.
2. Run oxerun under Xen like the smoke test does to verify the hypercalls work properly