On 04/20/2013 05:36:46 AM, Blue Swirl wrote:
> I plan to add a sparc64 target built from source to Aboriginal
Linux.
>
> For a lot of the 64-bit targets, actual 64 bit userspace support is
> strangely lacking. For ppc64 they say to use ppc32, and I've been
told that
> about sparc64 as well. I don't know if this is an optimization or a
> requirement. I have a 32 bit image, I'd like to test the 64 bit
codepaths as
> well...
It's a sort of optimization, the pointers are smaller. OpenBSD/sparc64
takes a different approach, every binary is 64 bits. Would it be hard
to make Aboriginal *BSD? ;-)
Not _that_ hard, but I'm not sure it's interesting?
Aboriginal Linux is basically 7 packages: linux, gcc, binutils, uClibc,
make, bash, and busybox. (I also add distcc so the native toolchain can
move some of the heavy lifting of compilation outside the emulator, but
that's optional.)
This is the smallest system capable of not only rebuilding itself under
itself, but building Linux From Scratch under the result (and thus
natively bootstrapping up to an arbitrary set of packages).
I'm gradually replacing busybox with toybox, and I'm migrating from
uClibc to musl. I vaguely plan to read the various klibc arch support
bits to add new architectures to musl, but my day job doesn't have
anything to do with my hobby programming so there's a chronic shortage
of time, and toybox 1.0 is my priority right now for reasons I blatered
at length about at ELC a month or so back (http://youtu.be/SGmtP5Lg_t0).
In theory swapping in a bsd kernel and libc, and beating the toolchain
into accepting it, might not be too hard. But what I'm more likely to
do is try to add sparc64 support to musl and convince the toolchain
it's just going to have to cope with the idea of a 64 bit sparc
userspace.
Rob