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

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

Larry Gray wrote:
> 
> >  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...
> >
> 
> Yes, I'm aware of this. However shouldn't gcc compile with m68k-unknown-coff,
> then different board variations can be setup later?

 CPU-targets like ARM, H8/300, SH, M32R, MN10200, MN10300 etc. have a 'default
target board', so my suspect has not so much motives. Problems like I wrote have
happened, but they have been related to using the linker alone, forgetting or
not knowing that the '-m<cpu>' must be used to select the right 'emulation' in
'ld', or that there are separate libs for the non-default CPU-variations under
the '$prefix/$target/lib'. But I don't remember the default target board causing
big troubles...

 When the 'm68020/m68881' is the default CPU and probably the MVME135 or MVME162
boards supported in newlib have this combination, why not put one of these as the
'default target' in those m68k-coff and m68k-elf configurations?  Of course this
needs someone to fight through the FSF-bureaucracy, or the CrossGCC FAQs or something
could have patches for fixing the m68k-coff/elf config file(s)
('gcc/config/m68k/m68k-none.h' alone?) for m68k-coff/elf. The 'LIB_SPEC',
'STARTFILE_SPEC', 'ENDFILE_SPEC', 'LINK_SPEC' and 'LIBGCC_SPEC' would then be those
specs needing fixing for the default target.

> >  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,....).
> 
> I suspected this, but without knowing the internal details of gcc and how it
> compiles, an error normally means its not going to work.

 Adding the earlier separate libiberty and libstdc++ into GCC has caused some
benefits, but also some troubles...

> >  Hmmm, sounds like ELF-stuff ("Exception_Handling_Frame_Begin"), so :
> 
> These errors were apparently related to newlib. By doing a 'make all install'
> in the existing build-newlib directory, then building gcc again, all worked.

 Browsing the doc-sources like 'tm.texi' about 'EH_FRAME_SECTION_ASM_OP' etc.
gives the influence that the '.eh_frame'-section doesn't belong to others than
ELF with DWARF2, but some Objsw-originated linker-scripts have this for m68k-coff
too... So I don't know whether the 'magic' was right or wrong... The alternative
would be to just add the section, like :

-------------------- clip -----------------------
*** mvme162.ld.orig	Sat Mar 18 00:48:51 2000
--- mvme162.ld	Thu Oct 18 01:00:15 2001
***************
*** 113,118 ****
--- 113,122 ----
      *(.shbss)
      *(.bss)
      *(COMMON)
+     __EH_FRAME_BEGIN__ = . ;
+     *(.eh_fram)
+     *(.eh_frame)
+     __EH_FRAME_END__ = . ;
      _end =  ALIGN (0x8);
      __end = _end;
    } > ram
-------------------- clip -----------------------

 This place (in '.bss') was copied directly from those Objsw-scripts...

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