newbie questions

[Ralf Corsepius]

Am Die, 2002-10-08 um 04.00 schrieb Till Straumann:
> Wulf Hofbauer wrote:
> 
> >Hi,
> >
> >I am trying to evaluate RTEMS for a DAQ/process control system
> >using a MVME147 board. I am pretty confused by the building
> >procedure.
> >
> >So far, I have been using an m68k-elf-gcc (3.2) and
> >m68k-elf-binutils (2.13) for the MVME147 on an x86 GNU/Linux
> >system, along with a homegrown port of newlib.
> >
> >The documentation in the RTEMS 4.5.0 tree as well as the
> >beginner's guide claim that some pretty ancient and customized
> >versions of gcc and binutils are required.
RTEMS 4.5.0 is ancient and so are its docs ;)

gcc-3.2 and binutils-2.13 probably won't work with rtems-4.5.0. However
gcc-3.2 and binutils-2.13 should work with the rtems snapshots.

> A customized version
> >of newlib also seems to be necessary just in order to build the
> >RTEMS kernel itself.
Right.

> >I'd prefer to work with the toolchain I have in place. Is it
> >really necessary to have specific versions of gcc and binutils
> >(if so, why)?
> >
> That's actually something I'd like to know myself.

Somewhat simplified:

1. RTEMS's gcc/newlib and binutils often contain bugfixes against known
bugs in gcc/newlib/binutils and special adaptations of these tools to
RTEMS.
Normally these patches will be merged into the official sources, but
given their release cycles, this process typically is slow, so providing
patched toolchains is an escape from this dilema.

2. There exists a bootstrap/"hen and egg" problem between newlib, RTEMS
and gcc, which is difficult to solve: RTEMS implements the lowlevel
OS-related parts of libc, newlib implements a set of general mid-level
parts of libc, RTEMS implements another set of these mid-level parts and
even worse, gcc also implements a certain set of libc-related parts
(libgcc rsp. libgcc_s).

Over the times the separation between all involved parts has changed
slowly, over-all resulting into incompatiblities between toolchains and
RTEMS. 
I.e "the glue" inside of RTEMS has changed and needs to be reflected in
other parts being involved. With gcc and newlib being publically
available, these changes have been reflected there.

3. gcc needs to be compiled against the libc (here: newlib) that is
actually used on the target, otherwise it won't work correctly in many
cases. Whether a non-rtems-gcc will work, therefore depends on if the 
target's rtems gcc/newlib had been subject to rtems-specific patches or
not and on a particular version of RTEMS.

I.e. Older versions of RTEMS very likely work with FSF versions of
gcc/newlib and binutils because all RTEMS patches required at the time
this RTEMS version was current, probably are contained in these
toolchains' sources. 

To summarize: It depends on various factors if your "non-RTEMS
gcc/binutils" toolchain will work with a particular version of RTEMS. I
recommend against trying this.

Newer versions of RTEMS will require newer toolchains, older versions of
RTEMS will require older toolchains.

> >
> >Also, the relation between RTEMS and newlib puzzles me. I'd
> >expect to build a C library on top of RTEMS if needed.
> 
> Hmm I wouldn't expect a clean separation between the layers
> but rather quite some amount of glue...
Exactly, this is one essental part core of the problem. But, ... RTEMS
has evolved, newlib has evolved, gcc has evolved and binutils has
evolved => "the glue" is in permanent motion.

> > The
> >apparent mutual interdependence strikes me as somewhat bizzarre.
> >
> Well, AFAIK, RTEMS implements parts of the C library (e.g.
> lowlevel-malloc, reentrancy, ...). Hence, you'd expect it to
> certainly depend on the newlibc headers. Also, newlibc
> needs probably be configured in a specific way so the build
> process 'knows' about what parts of the C library have to
> be provided by newlib and what is actually implemented by
> RTEMS.
Exactly, parts of RTEMS are "below newlib", parts of RTEMS are "above
newlib" and gcc is right inbetween.

This is not any different from other OSes, eg. Linux where interfacing
glibc2 and gcc is a similar problem (You might have heared about the "To
whom does /usr/include/[linux|asm] (aka. the kernel-headers) belong
issue). Try to build a linux from scratch and from sources only (without
having a linux c-compiler or glibc binary, you will encounter the same
issues then.

Ralf