Re: Can't build gcc-3.0.1 for m68k-coff

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Larry Gray wrote:
> 
>   I'm trying to build a cross compiler for m68k-coff with gcc-3.0.1,
> binutils-2.11.2, and newlib-1.9.0. As I mentioned in my previous message,
> I've followed "Getting Started with GNU" by William Gatliff, to the letter,
> with the exception of substituting m68k-coff for the target.
>   All goes well until I try to build the complete compiler, this fails with:
> 
> checking whether the C compiler (/newgcc/build-gcc/gcc/xgcc
> -B/newgcc/build-gcc/gcc/ -B/newgcc/install/m68k-coff/bin/
> -B/newgcc/install/m68k-coff/lib/ -isystem /newgcc/install/m68k-coff/include
> -g -O2 ) works... no
> configure: error: installation or configuration problem: C compiler cannot
> create executables.

 First a generic question about sanity:

 What target board, operating system etc. the target 'xyz-abc' describes?
Here the 'm68k-coff'...

 One can produce executables which run on DOS, Linux, Win95, Solaris2, or on
any standard opsys, or on a well-known target board with a well-known firmware
(a monitor etc.) on it.

 But what is the system 'm68k-coff' you now want your executables to run on?
When you have a clue about that, you can edit your 'specs' file by putting a
default 'target system' into it. The 'specs'-file which the 'xgcc -dumpspecs'
produces during the build is partially bullshit because nobody has had a clue
about what could be the suitable default target for 'm68k-coff' executables.
The '*_SPEC' settings in the config files are for 'nothing specified' as the
real target.

 The default CPU is the m68020/m68881 combination, so putting a MVME-board or
something which has the default CPU on it, would then cause all the CPU32 or
Coldfire users to scratch their heads and ask here why the compiled and linked
programs (for m68020/m68881 and the MVME-hardware) don't run on their target
boards...

 My opininion is that when the GCC-builder has passed this 'sanity check', and
becomes aware what is needed to "create executables" for something, there is
some hope that the rest will go better...

> make: *** [configure-target-libiberty] Error 1

 Yes, the libiberty-configure tries to test the C-library and the glue-library
(for the selected target board) by compiling and linking a simple test program.

 What comes to the "build a cross compiler for m68k-coff with gcc-3.0.1", you
have done it when the 'gcc'-subdir was passed!  Believe or not, this is the
'compiler' case... Now you can install your new GCC, build newlib with all the
target board support libraries (BSPs), ie. the 'glue libraries', besides the
'libc.a's and 'libm.a's for quite many m68k-CPU-variations (m6800, m68020, mcpu32,
m5200,....).

 After that you can try to compile and link a "Hello World" for running on
any of the supported target boards, upon the monitor on it.  Unfortunately
there aren't a stand-alone simulator, a 'm68k-coff-run' which would simulate
any of the target boards on the host system...  Many architectures have one,
please see the 'sim'-subdir in the GDB-sources...

 When the compiler and its settings are ok and you have a default target in
the 'specs' and know how to change it or remove it again, you can continue
building the libiberty and libstdc++ for 'm68k-coff'. Having some kind of
real target in the 'specs' enables the sanity check in libiberty-configure
to pass...

> David Korn (thanks David) suggested the problem is either a $PATH or config
> option problem. After some investigation I believe it is a config option
> problem, or more specifically a problem in configure.in. At the bottom of
> /newgcc/build-gcc/m68k-coff/libiberty/config.log I have:
> 
> /newgcc/build-gcc/gcc/libgcc.a(__main.o): In function `__do_global_dtors':
> /newgcc/build-gcc/gcc/../../gcc-3.0.1/gcc/libgcc2.c(.text+0x30): undefined
> reference to `__EH_FRAME_BEGIN__'

 Hmmm, sounds like ELF-stuff ("Exception_Handling_Frame_Begin"), so :

E:\usr\local\lib\gcc-lib\m68k-elf\2_95.3-1>\usr\local\m68k-elf\bin\nm crtbegin.o

00000000 ? __CTOR_LIST__
00000000 ? __DTOR_LIST__
00000000 ? __EH_FRAME_BEGIN__
         U __deregister_frame_info
         U __register_frame_info
00000000 d force_to_data
00000000 t gcc2_compiled.

E:\usr\local\lib\gcc-lib\m68k-elf\2_95.3-1>\usr\local\m68k-elf\bin\nm crtend.o
00000000 ? __CTOR_END__
00000000 ? __DTOR_END__
00000000 ? __FRAME_END__
         U __deregister_frame_info
         U __register_frame_info
00000000 d force_to_data
00000000 t gcc2_compiled.

 Somehow the ELF/DWARF-stuff has polluted the COFF-configuration... this is only
a plain vanilla bug in gcc-3.0.1...

> /newgcc/install/m68k-coff/lib/libc.a(abort.o): In function `abort':
> /newgcc/build-newlib/m68k-coff/newlib/libc/stdlib/../../../../../newlib-1.9.0/newlib/libc/stdlib/abort.c:63:
> undefined reference to `_exit'
> /newgcc/install/m68k-coff/lib/libc.a(signalr.o): In function `_kill_r':
> /newgcc/build-newlib/m68k-coff/newlib/libc/reent/../../../../../newlib-1.9.0/newlib/libc/reent/signalr.c:61:
> undefined reference to `kill'
> /newgcc/install/m68k-coff/lib/libc.a(signalr.o): In function `_getpid_r':
> /newgcc/build-newlib/m68k-coff/newlib/libc/reent/../../../../../newlib-1.9.0/newlib/libc/reent/signalr.c:96:
> undefined reference to `getpid'
> /newgcc/install/m68k-coff/lib/libc.a(sbrkr.o): In function `_sbrk_r':
> /newgcc/build-newlib/m68k-coff/newlib/libc/reent/../../../../../newlib-1.9.0/newlib/libc/reent/sbrkr.c:61:
> undefined reference to `sbrk'
> collect2: ld returned 1 exit status
> configure: failed program was:
> 
> I not sure about the __EH_FRAME_BEGIN__, but aren't abort, kill, getpid, and
> sbrk supposed to be located in newlib's hardware specific library, like
> libbcc.a or libnosys.a? Why would gcc need access to these libraries while
> it's building itself? Or does this point to a problem with newlib-1.9.0?

 GCC definitely is not building itself, the 'xgcc' is the GCC-driver for the
new cross-compiler and the new compiler is tried to be used to build the extra
libiberty and libstdc++ libraries now included with the GCC sources... With the
gcc-2.8.1 and earlier, GCC was only the 'gcc' subdir (perhaps libiberty was
there to be compiled only with the 'host' compiler). 

 The idea in 'libiberty' is that it has those 'missing' functions, not present in
the 'libc'. The way used to find them is to compile test programs which call all
kind of functions and find those 'undefined' ones... But before this a sanity-check
is done with a simple program. It must compile and link without any problems. If
this doesn't succeed, the famous "C compiler cannot create executables" appears...

 The problem is that this message should put bells ringing and the question
"What in the hell is the target for the executables?" should arise... If this
doesn't happen, it is the problem...

 Currently there aren't any kind of sane target in the defaults, so the build
doesn't know which m68k-board and its glue-library should be used when linking.
Everything has been left to the embedded engineer who really should know these
things about linker scripts, startups, libraries, interfacing with the hardware
etc. At least the primary-level things like "What are the headers?", "What are
the C-libraries", "Which functions a C-program uses to communicate with the
hardware?" Any course called "Using C in embedded programming" or something is
expected to handle these things... If not, where is the sanity in these university
etc. courses?

 For self-education books like "Programming Embedded Systems in C and C++" by
Michael Barr or "Programming with GNU Software" by Mike Loukides and Andy Oram
(both from O'Reilly) could be recommended. Probably there are others, but the
idea about the reader becoming aware of the memory maps, interfacing etc.
things should be present in both...

 When you even tried to build newlib at the same time with GCC, you had a blind
trust that "it should work straight from the box because the GNU guys have made
these sources". "Just prepare the sources, run a script from some FAQ and everything
works and the whole toolkit will be built"...

 Be welcome to meet the crude and cold reality!  Normally people see the 'elf'
in the target name being the magic creature who makes sure that everything will
go magically right and all kind of dwarfs with hobbits will help in this... I'm
still not sure whether a cup of coff'ee will do the same ;-)

 Doing things one at a time and checking the results got this far is some times
easier. Fixing bugs one at a time is also more easy...

 In this case the __EH_FRAME_BEGIN__ seems to be some bug in the configuration
and discussing about how it could be fixed is motivated... At the same time
preparing the 'specs' to use the linker script and the extra startups must be
done...

 Let's take the 'mvme135.ld' as our linker script for the 'default target' :

-------------------------- clip ---------------------------------------------
STARTUP(crt0.o)
OUTPUT_ARCH(m68k)
/* Uncomment this if you want srecords. This is needed for a.out
 * if you plan to use GDB.
OUTPUT_FORMAT(srec)
 */
SEARCH_DIR(.)
GROUP(-lmvme135 -lc -lgcc)
__DYNAMIC  =  0;

/*
 * Setup the memory map of the Motorola MVME135 Board
 * stack grows down from high memory.
-------------------------- clip ---------------------------------------------

 The 'crt0.o' is defined here (STARTUP), just as the libs to link (GROUP).

 So putting the same into the 'specs' may cause troubles, so leaving them
away is best (no other target stuff than the linker script name there) :

-------------------------- clip ---------------------------------------------

*endfile:


*link:


*lib:
-T mvme135.ld%s

*libgcc:


*startfile:


*switches_need_spaces:
-------------------------- clip ---------------------------------------------

 Ok, after the fixes in the 'specs' a normal 'compile' should produce something
like:

-------------------------- clip ---------------------------------------------
 /usr/local/m68k-coff/bin/as -mc68332 -o /tmp/ccYWsF01.o /tmp/ccqiwjT0.s
 /usr/local/lib/gcc-lib/m68k-coff/3.0.1/collect2 -o tst_m68k-coff-b.x \
-L/usr/local/lib/gcc-lib/m68k-coff/3.0.1 -L/usr/local/m68k-coff/lib \
/tmp/ccYWsF01.o -T /usr/local/m68k-coff/lib/bcc.ld
/usr/local/lib/gcc-lib/m68k-coff/3.0.1/libgcc.a(__main.o)(.text+0x30):
libgcc2.c: undefined reference to `__EH_FRAME_BEGIN__'
/usr/local/lib/gcc-lib/m68k-coff/3.0.1/libgcc.a(__main.o)(.text+0x50):
libgcc2.c: undefined reference to `__EH_FRAME_BEGIN__'
collect2: ld returned 1 exit status
-------------------------- clip ---------------------------------------------

 My 'default target' is the BCC with m68332, so the 'bcc.ld' and the option
for 'as' here...

 The __EH_FRAME_BEGIN__ in function `__do_global_dtors' is a bug, the symbol
should not be used in the '__main()' there, and this must be fixed somehow...

 After a little research my suggestion would be :

1. To patch the 'gcc/config/m68k/coff' with:

-------------------------- clip ---------------------------------------------
*** coff.h.orig	Mon Sep 25 16:22:45 2000
--- coff.h	Tue Oct 16 22:06:43 2001
***************
*** 30,35 ****
--- 30,39 ----
  
  #include "dbxcoff.h"
  
+ /* All configurations that don't use elf must be explicit about
+    not using dwarf unwind information. */
+ #define DWARF2_UNWIND_INFO 0
+ 
  /* COFF symbols don't start with an underscore.  */
  
  #undef USER_LABEL_PREFIX
-------------------------- clip ---------------------------------------------

and to patch the 'gcc/defaults.h' with:

-------------------------- clip ---------------------------------------------
*** defaults.h.orig	Tue Sep 25 15:45:09 2001
--- defaults.h	Wed Oct 17 00:12:33 2001
***************
*** 197,203 ****
  #define DWARF2_UNWIND_INFO 1
  #endif
  
! #if defined (DWARF2_UNWIND_INFO) && !defined (EH_FRAME_SECTION)
  # if defined (EH_FRAME_SECTION_ASM_OP)
  #  define EH_FRAME_SECTION() eh_frame_section ()
  # else
--- 197,203 ----
  #define DWARF2_UNWIND_INFO 1
  #endif
  
! #if DWARF2_UNWIND_INFO && !defined (EH_FRAME_SECTION)
  # if defined (EH_FRAME_SECTION_ASM_OP)
  #  define EH_FRAME_SECTION() eh_frame_section ()
  # else
-------------------------- clip ---------------------------------------------

 Whether this "removing the ghosting dwarf"-method is white or black magic,
will be seen... It worked for me.

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com