Date: Tue, 27 Dec 2016 12:13:46 -0800 From: John Baldwin <jhb@freebsd.org> To: Juli Mallett <juli@clockworksquid.com> Cc: "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: External toolchain friendliness and /usr/lib32 for mips64 Message-ID: <17902308.cnRfHqtlNY@ralph.baldwin.cx> In-Reply-To: <CACVs6=-CiZRBVX1SmDFkwLEeEFGeVrGQWWKLrM0gMG7QuGhd3w@mail.gmail.com> References: <2978934.3KKo4yUUSV@ralph.baldwin.cx> <CACVs6=-CiZRBVX1SmDFkwLEeEFGeVrGQWWKLrM0gMG7QuGhd3w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, December 23, 2016 03:09:36 PM Juli Mallett wrote: > 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 think it would end up being larger to do that, but I'm open to whichever makes sense. > 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? I can't get an n32 world to work at all in qemu currently much less testing freebsd32 compat. :-/ > 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. If we supported x32 on x86, yes, we would want x32 packages I think, but n32 is different because you can build an n32 world. I would only imagine x32 as an optional abi on amd64, so you wouldn't have an x32 kernel or a pure x32 world, but an amd64 kernel/world with a /usr/libx32 and the ability to build certain binaries as x32. With mips though you can have an n32 kernel/world where all the native binaries are n32. You would want a 'cc' in such a world to generate n32 binaries by default. In the model of external toolchains that would mean having a base/gcc package for n32 that builds a 'default-to-n32' cc. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17902308.cnRfHqtlNY>