[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Patches to fix building m68k with CPUFLAGS
On 2020/07/20 12:14, Jake Hamby wrote:
After further testing, I found that GCC 8.4.0 generates bigger, and
very buggy code, for m68k. I've seen no freezes, uvm errors, or panics
on illegal instructions with the NetBSD-current build I made with
"-m68040" and my previous patch, minus the part to change HAVE_GCC
from 7 to 8.
Yes, amiga kernel does not work correctly if compiled by GCC8. See more
details in this thread:
On 2020/07/20 3:20, Jake Hamby wrote:
One more note on the "libgcc/config/m68k/lb1sf68.S" patches (to gcc
The reason you only see a failure
here with CPUFLAGS set is because, I suspect, "defined (__mcoldfire__)
&& !defined (__mcfisab__)" must be defined in the default
configuration, and not if you use, e.g. "-m68040" or "-m68020-60"
(which should be the ideal default build flag for targets like Atari
ST and Amiga).
This is not correct. __mcoldfire__ is not defined for our m68k ports.
You can confirm this by:
% m68k--netbsdelf-gcc -dM -E - < /dev/null | grep coldfire
Also you can see braw is used for the library compiled without
optimization flags as:
% m68k--netbsdelf-objdump -d libgcc_s.so | grep _exception_handler
I guess that libgcc_s can be compiled without -m68040 or -m68060, just
because the generated code is small enough. In order to work this around,
you can simply replace bra with bral in that file. Alternatively, you
can build the library by skipping tsort and lorder:
On 2020/07/20 2:35, Jake Hamby wrote:
@@ -298,7 +298,7 @@
#define TARGET_ALIAS "m68k--netbsdelf"
/* Define as 1 if big endian. */
-/* #undef TARGET_BYTES_BIG_ENDIAN */
+#define TARGET_BYTES_BIG_ENDIAN 1
/* Canonical target. */
#define TARGET_CANONICAL "m68k--netbsdelf"
This patch is not necessary because m68k is purely big-endian platform,
and TARGET_BYTES_BIG_ENDIAN is unconditionally defined in
Your patch for external/gpl3/gcc/dist/gcc/config/m68k/m68k.h seems
rational. I'd appreciate a lot if you could report this to upstream.
As you pointed out, CPUFLAGS should be neglected in order kernel and
some standalone programs to get compiled. However, I'm not sure whether
share/mk/bsd.sys.mk is the best place to do this.
Main Index |
Thread Index |