[mkroot] x32 mcm-buildall.sh final patch

[Rob Landley]

On 03/03/2018 02:38 PM, Alain Toussaint wrote:
> 
>> The larger question here is "toolchain the kernel builds with and toolchain
>> userspace builds with are different".

In general infrastructure to build kernel with one toolchain and userspace with
another is probably good to have...

> Yeah, on that count, I need to do a patch for the x86_64 kernel build to include the x32
> compatiblities settings. That being said, when I was hacking the prototype, the kernel got built by
> the x32 toolchain but I don't know (yet) if a kernel built by the x32 toolchain would see past 4GB.
> It did build fine and worked under qemu.

Libtomcrypt in dropbear couldn't cope. Possibly I should be using a version
newer than 2016? :)

Hmmm... I wonder if it's the same kernel or a different kernel? (If it's
defaulting to 32 bit and sticking the long prefix in front of everything it'd
work the same but the code would be enormous. That's _probably_ not what's
happening but I'd wanna diff the binaries to be sure...)

The x32 bzImage is 2420688 bytes, the x86_64 bzImage is 2428880 bytes. About an
8k difference in a 2.4 megabyte file. I'd dig deeper but I need the vmlinux (not
the bzImage) to do that properly. In the meantime, maybe I need an option for
keeping the vmlinux files around for study after the build? (Back in aboriginal
linux I had NO_CLEANUP=1, and I can add that back here, but

(It's a pity that qemu can't universally boot a vmlinux on all targets. The
plumbing's sort of there but qemu -kernel has definite format expectations that
vary from target to target. Sigh...)

> For bare metal, I already had a 64bit kernel with the suitable options on a multiboot usb key.
> 
>>  And the OTHER problem is that x86_64-*-native
>> now resolves to two toolchains.
> 
> That is the bit I was refering to which is why I set the x86_64 arch to x32 on the first patch so
> that running ./cross.sh x86_64 ./mkroot dynamic kernel built an x32 kernel and userspace.

Yeah, needs some new design work. (The user interface is harder to get right
than the plumbing.)

Hmmm... what I'd like to do is rename the toolchain at build time so it's
x32-linux-musl-cross, assuming that doesn't confuse autoconf? (It shouldn't.)
Literally all the cross.sh script does is set CROSS_COMPILE to the prefix (with
path) of a cross compiler, and then CROSS_SHORT is re-derived from that in
mkroot.sh...

That's still building the kernel and userspace with the same toolchain, but if
it works in this case I can defer adding better infrastructure until I hit a
case that doesn't. (I should still fix this for mmu and nommu versions of the
same architecture, ala microblaze.)

> Alain

Rob