This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |