Port-i386 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

i386 vs i486, some inconsistencies

Last week I've fixed a problem in pkgsrc/djvulibre where
the code used a compiler builtin which works only for
i486+ while the toolchain assumes an i386 per default.
The pkg was partly guilty because a "configure" check
was incomplete, but there are also inconsistencies
on our side.

If the compiler can't translate the builtin directly
because the target doesn't support that machine
instruction (eg. cmpxchgl), it issues a call to a
function (eg. __sync_bool_compare_and_swap_4) which needs
to be provided by a runtime library. Ours doesn't, so
we get unresolved symbols.

Since i386 support was removed from the kernel in 5.x,
and appearently noone is going to fix it anyway,
we could as well change the toolchain default to 486.
This would make the runtime library support practically
unnecessary. (I didn't check what happens with -fno-builtin,
but that's not a real problem.)
So I tried and came to the appended patch.
There is an inconsistency in the GNU toolchain in how
a target specifier of "i486--netbsd*" affects the result:
gcc basically translates this into "-mcpu=i486" which
means "tune for i486" while keeping the code runnable
on i386. libstdc++ starts to use "xadd" which makes
it i486+ only. (Btw, "-mcpu=x" is listed as deprecated
but supported in the docs but in reality it doesn't
work at all on the gcc command line.)

Because "tune" is not sufficient to get cmpxchg et al
into use, the --with-arch configure argument was needed.
This translates into "-march=x" which dtrt.
Unfortunately this affects all ports instead of
just i386, so there might be side effects. It doesn't
look serious at the first glance, but it would need
to be tested.
One could also sort that out in bsd.own.mk. Actually,
the way MACHINE_GNU_PLATFORM is constructed seems not
completely consistent with GNU documentation: GNU
says "CPU-COMPANY-SYSTEM" while bsd.own.mk does
One could seperate GNU_ARCH and GNU_CPU but I'm not
sure this is worth the effort.

What do you think?

best regards

(In case it is not obvious: The patch needs a round
of "mknative" to affect the native compiler.)

Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
# old_revision [60f178ae9b1dfb28c01b9d8f88a1553c69f02a5e]
# patch "share/mk/bsd.own.mk"
#  from [c4d06e1d4b4b5868ff915008ecb1b5941bb169c1]
#    to [892273a1e9b5e5af37964e949c230b569502286e]
# patch "tools/gcc/Makefile"
#  from [be82bc356632ddc4abbf5fef78def926dca67e13]
#    to [f2305a2d1feb88b71ff64084af9fa8183e79907f]
--- share/mk/bsd.own.mk c4d06e1d4b4b5868ff915008ecb1b5941bb169c1
+++ share/mk/bsd.own.mk 892273a1e9b5e5af37964e949c230b569502286e
@@ -528,6 +528,7 @@ GNU_ARCH.coldfire=m68k
 # GNU sources and packages sometimes see architecture names differently.
--- tools/gcc/Makefile  be82bc356632ddc4abbf5fef78def926dca67e13
+++ tools/gcc/Makefile  f2305a2d1feb88b71ff64084af9fa8183e79907f
@@ -17,6 +17,7 @@ CONFIGURE_ARGS=       --target=${MACHINE_GNU_P
 CONFIGURE_ARGS=        --target=${MACHINE_GNU_PLATFORM} --disable-nls \
+               --with-arch=${MACHINE_GNU_ARCH} \
                --enable-long-long \
                ${MULTILIB_ARGS} \
                --enable-threads \
@@ -86,6 +87,7 @@ native-gcc: .native/.configure_done
--build=`${.CURDIR}/../../gnu/dist/${MODULE}/config.guess` \
                        --host=${MACHINE_GNU_PLATFORM} \
                        --target=${MACHINE_GNU_PLATFORM} \
+                       --with-arch=${MACHINE_GNU_ARCH} \
                        --enable-__cxa_atexit) && \
                (cd .native && ${MKNATIVE_ENV} ${BUILD_MAKE} 
 .if ${HAVE_GCC} == 4

Home | Main Index | Thread Index | Old Index