Re: Can't build gcc-2.95.3 with g++ for m68k-elf

[Wolfgang Fritz <wolfgang dot fritz at gmx dot net>]

Kai Ruottu schrieb:
> 
> Wolfgang Fritz wrote:
> >
[cut]
> >
> > Is there any documentation available how to make a "running" m68k
> > compiler without manual action? I tried to find out from the sources how
> > to do it, but gcc sources / configuration scripts are too hard for me.
> 
>  No, but a short doc comes here:
> 
>  The 'gcc/configure' script ('gcc/config.gcc' in 3.x) has the host/target templates
> defining the used config files, additions to the generated 'gcc/Makefile' (host/target
> overrides, the 'x-' and 't-' files) etc. For the 'm68k-' cases (they are choices in a long
> 'case'-switch), probably the templates are named as 'm68k-*-coff | m68020-*-coff' and
> 'm68k-*-elf | m68020-*-elf'.
> 
>  Looking at the template one can see that the main config header ('tm_file') for 'm68k-elf'
> is 'gcc/config/m68k/m68020-elf.h' or something, there may be 'gcc/config/elfos.h' (generic
> defs for an ELF-target) etc. included before it and so on... During the build the
> '$build/gcc/tm.h' has these 'target config headers' listed/chained for inclusion....
> 
>  The same thing may be defined and then undefined/defined again many times in the
> config-headers chain, but the last one is the final...
> 
>  Those 'LINK_SPEC', 'LIB_SPEC', 'STARTFILE_SPEC', 'ENDFILE_SPEC' etc. in these
> config-headers define what will be put into the resulted 'specs' as default...
> 
>  So it wouldn't be a problem to put any of the newlib-supported target boards to
> be the default target in the FSF-sources, after learning the config mechanism and
> editing or adding the final definition for a spec. It may be necessary to #undef
> and #define again something, if this was defined last in some generic header for
> many targets and it is wrong for the specific target.
> 
>  Anyway here is the end of the 'gcc/config/m68k/m68020-elf.h' in my gcc-2.95.3
> sources:
> 
> ------------------------ clip --------------------------------
> #undef LIB_SPEC
> #define LIB_SPEC        ""
> 
> #undef LIBGCC_SPEC
> #define LIBGCC_SPEC     ""
> 
> #undef LINK_SPEC
> #define LINK_SPEC       ""
> 
> #undef  STARTFILE_SPEC
> #define STARTFILE_SPEC  "crtbegin.o%s"
> 
> #undef  ENDFILE_SPEC
> #define ENDFILE_SPEC    "crtend.o%s -T mvme162.ld%s"
> 
> /* end of m68020-elf.h */
> ------------------------ clip --------------------------------
> 
> > The problem hurts most if you start to build the cross toolchains from
> > scratch (building newlib-1.10.0 stops with the same error). I would like
> > to build a patch to the gcc sources so gcc builds for a "dummy" 68k
> > target or if you have your board support package already, to build a
> > libgloss for that target. As a start point for learning the build could
> > generate a working compiler for one of these VME boards in the 68k
> > libgloss directory.
> 
>  For the current 'm68020' CPU-default perhaps one of the VME-boards could be
> the default. They seem to have a big enough memory-space for C++ too...
> 
>  The 'cpu32' case may be problematic, the BCC-target hasn't enough memory,
> so those 'hello.cpp' tries using the 'bcc.ld' will lead into weird? (but
> very educating...) problems. So although the 'bcc.ld' could look like a nice
> candidate for a cpu32 target, it brings some problems...
> 
>  Ok, my thought is that the 'm68k-coff/elf' could be splitted to three CPU-
> variations, 'm68k-' for the m680?0, 'mcpu32-' for cpu32/m683?? and 'm5200-'
> for Coldfire and each of them having a suitable default target board.
> Adding new templates to configure/config.gcc isn't that hard and providing
> new 'cpu32-elf.h', and 'm5200-elf' etc. config files as the 'tm_file' using
> the 'm68020-elf.h' as the base, isn't either...
> 
>  The problem is to find a person who wants to struggle with getting these
> fixes included into the FSF-sources...
> 

meanwhile I've managed to get the specs and linker file for my target to
be set up as I want during the gcc build. Now newlib-1.10.0 builds
successfully (it had the same errors as libiberty).

For my "real life" applications I have one problem that I couldn't solve
up to now. I have one application which needs a special linker script
which is conflicting with the default linker script from the specs file.
I have the following entry in the specs file:

*link:
%{!T:-T dt.ld%s}

which LOOKS to me as it would mean "If there are no -T options on the
linker command line, use the default dt.ld, otherwise don't". That is
what I want. But dt.ld is always used, and my special application gives
nice error messages during the link.

I could not find documentation about the specs entries (I'll keep on
searching). Is ther a solution for this problem which I would imagine is
a common one in embedded systems with differing memory layouts etc.

Wolfgang
 
> Regards, Kai
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

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