n64/n32 - build support patches

M. Warner Losh imp at bsdimp.com
Fri Mar 5 15:22:34 UTC 2010


CJ,

Thanks for all the work in this area.  I know that Julie Mallett is
also working in this area, and I've done some work to clean up the
build system.  I'm afraid that we now have some conflicts between the
different efforts, and that it may take a little to resolve the
conflicts.


In message: <98a59be81003050215m753799dbu35d2b2eab65e75db at mail.gmail.com>
            "C. Jayachandran" <c.jayachandran at gmail.com> writes:
: I've updated the patches for building n64 and n32 kernel and
: userspace,  please review. The patches are:
: 
: Tool chain support for n64 and n32::
: http://sites.google.com/site/cjayachandran/files/n64-n32-toolchain.patch

: This updates the gcc configuration  to provide the default ABI, linker
: scripts and endianness flags during n64/n32 and o32 builds. With this
: change, we don't need the -Wl, flags for linker emulation, the mabi
: flags or the -EB/-EL for compiler.

This part of the patch looks good.

: I had to add a make variable in TARGET_DEFINES in
: gnu/usr.bin/cc/Makefile.tgt and use that to pass the defaults while
: creating 'tm.h' - this change is not MIPS-specific.

TARGET_DEFINES is OK.  I'm not sure about the other Makefile variables
and would like to find some way to not need them.

: User/kernel build with n64 and n32:
: http://sites.google.com/site/cjayachandran/files/n64-n32-build.patch
: 
: updated bsd.cpu.mk which does not set LDFLAGS, adds ldscript.mips.n32
: and removes unnecessary flags from Makefile.mips.

+.if ${MACHINE_ARCH} == "mips"
+. if defined(TARGET_64BIT)
+.  if defined(TARGET_BIG_ENDIAN)
+LD += -melf64btsmip_fbsd
+.  else
+LD +=  -melf64ltsmip_fbsd
+.  endif
+. elif defined(TARGET_N32)
+.  if defined(TARGET_BIG_ENDIAN)
+LD += -melf32btsmipn32_fbsd
+.  else
+LD +=  -melf32ltsmipn32_fbsd
+.  endif

I'd rather find some way to avoid adding TARGET_64BIT, TARGET_N32.
I've been working to eliminate TARGET_BIG_ENDIAN because it is proving
to be unworkable in practice, especially as these machines become more
self-hosting.

If you don't mind, I'll pull in the parts that don't conflict with the
other work in this area, and we can then look at the harder problem of
which pieces of that goes in.

Warner


More information about the freebsd-mips mailing list