tsort(1) v.s. libgcc_s for m68k

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

Hi,

libgcc_s does not build for a long time for m68k with CPUFLAGS=-m68060,
etc., which increases a code size a bit; offsets for bra instructions
exceed 16bit limit for gcc/dist/libgcc/config/m68k/lb1sf68.S.

I've found why this affects us while does not Linux people; we are
changing order of objects by tsort(1) when linking libraries. Actually,
a hack below enables us to build libgcc_s with, e.g., -m68060.

----
--- external/gpl3/gcc/lib/libgcc/libgcc_s/Makefile	21 Oct 2016 23:44:09 -0000	1.14
+++ external/gpl3/gcc/lib/libgcc/libgcc_s/Makefile	22 Mar 2019 16:54:06 -0000
@@ -56,6 +56,12 @@ LIBGCC_S_OBJS=	${OBJS}
 LIBGCC_STD_VER_IN=	${GNUHOSTDIST}/libgcc/libgcc-std.ver.in
 CLEANFILES+=		libgcc-std.ver
 
+.if ${MACHINE_ARCH} == "m68k"
+# XXX Hack for word-offset branches working as expected.
+LORDER=		echo
+TSORT=		cat
+.endif
+
 libgcc-std.ver:	${LIBGCC_STD_VER_IN}
 	${_MKTARGET_CREATE}
 	${TOOL_SED}  -e 's/__PFX__/__/g' -e 's/__FIXPTPFX__/__/g' < ${LIBGCC_STD_VER_IN}  > ${.TARGET}.tmp
----

Note that increase in code size with -m68060 is small. This means that
libgcc_s can become uncompilable even without optimization flags in the
near future.

I wonder whether tsort(1) is really necessary for the modern linkers.
Or, more restrictively, can't we skip tsort(1) when order of objects
are expected to be already sorted by the upstream?

For m68k libgcc_s, as John suggested to me, we can avoid the problem by
replacing bra instruction with bral, which accepts 32bit offsets. However,
I'd prefer not to modifying source code itself, in order to reduce diff
with the upstream as well as code size.

Thanks,
rin