Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Dec 2016 15:09:36 -0800
From:      Juli Mallett <juli@clockworksquid.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org>
Subject:   Re: External toolchain friendliness and /usr/lib32 for mips64
Message-ID:  <CACVs6=-CiZRBVX1SmDFkwLEeEFGeVrGQWWKLrM0gMG7QuGhd3w@mail.gmail.com>
In-Reply-To: <2978934.3KKo4yUUSV@ralph.baldwin.cx>
References:  <2978934.3KKo4yUUSV@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi John,

On Fri, Dec 23, 2016 at 2:13 PM, John Baldwin <jhb@freebsd.org> wrote:
> I have a set of patches (currently tied together, but could be split
> into two chunks) for MIPS builds that do two things:
>
> 1) Be more external toolchain-friendly by explicitly specifying the
>    desired endianness and ABI both to the compiler and the linker.
>    This means we don't depend on the default target of a toolchain
>    matching the desired target arch.  Previously, I had to explicitly
>    specify a TARGET_CPUTYPE for 32-bit mips when using
>    mips-xtoolchain-gcc, but with the ABI set explicitly simply
>    'TARGET_ARCH=mips' is sufficient.  This also means that you can
>    now use 'mips-xtoolchain-gcc' to build mips64 (without
>    requiring the separate mips64-xtoolchain-gcc), and you can
>    build mipsn32 with gcc from ports (we don't have a binutils or
>    gcc port for mips that defaults to mipsn32 currently).
>
> 2) Add build glue for /usr/lib32 on mips64.  This builds and installs
>    an o32 set of libraries and rtld (of matching endianness) in
>    /usr/lib32.
>
> I have tested the latter with the MALTA64 kernel config (just adding
> COMPAT_FREEBSD32) under qemu and am able to run 32-bit binaries just
> fine.
>
> Note that for 1), there is still the case that if we build a compiler
> via the base/ ports, we want the default output to match the host,
> so we would need a mips64-specific base/gcc separate from the mips
> one (and we need a mipsn32 set of packages).
>
> One annoyance is in the sys/boot/beri ldscripts.  In-tree binutils
> uses 'elf64-trad*mips' for its ABIs on FreeBSD while upstream
> biutils uses 'elf64-trad*mips-freebsd'.  However, the ldscripts are
> already being linked with a linker that is using 64-bit MIPS (and
> are only built for "mips64"), so the OUTPUT_FORMAT() isn't really
> needed and can just be removed.  I'd probably want to also remove
> OUTPUT_ARCH() as well as I think that would be most consistent.
>
> The patches are at:
>
> https://github.com/freebsd/freebsd/compare/master...bsdjhb:mips_lib32

I've looked these over and they look good to me.  There were a few
things that caught me off-guard, and then looked right.

I'd suggest Makefile.libcompat doing something like ld/Makefile.mips
does with ${_EMULATION_ENDIAN}, so that the almost identical o32 LD
settings can be combined.

I recall making COMPAT_FREEBSD32 in the kernel work with n32 kernels
and o32 in userland, I don't suppose you've tried that to see if it
still works?  If so, since the userland changes are so small, it seems
like they might be worth throwing in here?

As to us needing a n32 package sets, I think that might be a bit of a
stretch.  If we go down the x32 route for amd64, would we be having
x32 packages, too?  I guess if we have the resources to build the
extra package sets for MIPS, there's no reason not to, but I'm
skeptical of their value.  I know that's not in this change, but as
part of the larger arc here.

Thanks very much for doing this work!

Juli.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=-CiZRBVX1SmDFkwLEeEFGeVrGQWWKLrM0gMG7QuGhd3w>