Problems with RTEMS 4.0.0 (long)

[Charles.Gauthier at iit.nrc.ca (Charles Gauthier)]

I succesfully built RTEMS 4.0.0 for a Motorola MVME167. Most tests ran as
expected. However, I did encounter some problems. I am posting a description of
these problems in the hope of improving RTEMS. Also, others who encounter the
same problems may benefit from this message.


Build Problems #1: --enable-gcc28 did not work properly.
--------------------------------------------------------

I already had gcc 2.8.1 and binutils 2.9.1 built as m68k-rtems cross development
tools (for RTEMS 3.6.0) on an RS/6000 running AIX 4.2.0.0. I therefore decided
to keep these tools and to build newlib 1.8.0 and RTEMS without using the build
scripts "bit" and "bit_rtems". The patched newlib 1.8.0 built without any
problems. No so with RTEMS. After adding the MVME167 BSP files, I configured
RTEMS with:

  --target=m68k-rtems --enable-rtems-inlines --enable-posix \
  --enable-cxx --enable-gcc28 --prefix=/usr/local

and then did:

  make RTEMS_BSP=mvme167

The build stopped in rtems/c/src/exec/posix/src/key.c with
PTHREAD_DESTRUCTOR_ITERATIONS undefined.  The problem is that the
/usr/local/lib/gcc-lib/m68k-rtems/2.8.1/include/limits.h file was included
rather than rtems/c/src/exec/posix/base/limits.h, which is where the missing
manifest constant is defined. With --enable-gcc28, the search path order is:

  ~/build-rtems/mvme167/lib/include
  /usr/local/lib/gcc-lib/m68k-rtems/2.8.1/include
  /usr/local/m68k-rtems/include

These paths correspond to PROJECT_INCLUDE, GCC_INCLUDE and
RTEMS_LIBC_DIR/include respectively. The last two paths are the ones built into
the compiler, as reported by m68k-rtems-gcc -v. The search paths should be
PROJECT_INCLUDE, RTEMS_LIBC_DIR/include and GCC_INCLUDE, as defined in
rtems/make/compilers/gcc-target-default.cfg.

I had to configure RTEMS with

  --disable-gcc28 --enable-libcdir=/usr/local/m68k-rtems

instead of --enable-gcc28. The compiler is then invoked with -I options to
explicitly specify the include directories.

My copy of egcs-1.1.1 built as a m68k-rtems cross compiler under cygwin32 has
the following built-in paths:

   \usr\local\lib\gcc-lib\m68k-rtems\egcs-2.91.60\include
   \usr\local\m68k-rtems\sys-include
   \usr\local\m68k-rtems\include

It would have the same problem.

I did not see anything in the egcs-1.1b rtems patch to change the default search
order for include files. I did not attempt to apply this patch to gcc-2.8.1!


Build problem #2: Make cannot be restarted in some cases.
---------------------------------------------------------

I had to issue make RTEMS_BSP=mvme167 several times while fixing by BSP files.
Subsequent invocations of make all failed at the point of copying
rtems/c/src/lib/libbsp/m68k/mvme167/bsp_specs to
build-rtems/c/src/exec/score/cpu/m68k/o-mvme167/bsp_specs.tmp. The bsp_specs
file is maintained in CVS and checked out read-only. It is copied as read-only.
Subsequent attempts to recopy the file fail. I had to modify rtems/make/leaf.cfg
to force the copy.


Run Problem #1: RTEMS programs are not restartable.
---------------------------------------------------

An RTEMS program cannot be restarted without a fresh download, or some more
clever initialization code. The general problem is that some data in the .data
section is modified at run time. Restarting a program after a clean exit does
not work because the modified data no longer has the proper initial values.
Also, it makes it impossible to use a .data section placed in ROM directly.

The struct libc_global_reent in rtems/c/src/lib/libc/newlibc.c is one such
instance. It is initialized statically in the source file, which causes the
linker to allocate it in the .data section.

One solution is to not initialize the structure statically, but rather to
initialize it dynamically; it then gets allocated in the .bss section and gets
the proper initial values on every program start.

An alternative approach is to copy the .data section into RAM at boot time. This
approach is easy to implement when data is accessed using base relative
addressing rather than absolute addressing. With absolute addressing, it
complicates the build process because the application must be linked againts
initialized data at given addresses, but the initialized data must be placed
somewhere else (typically a ROM).


Run Problem #2: interrupts at initialization time.
--------------------------------------------------

The cdtest sample did not work with interrupt-driven I/O. This sample declared
two global C++ objects. The constructors for these objects call printf(). The
constructors are called from __do_global_ctors(), which is called from __main(),
which is itself called from main(). This last function is called at
initialization time, when the CPU interrupts are still disabled.

I am guessing that cdtest goes into an infinite loop in the second constructor
waiting for printf() to write to a full output buffer that will never empty
because the interrupts are not recognized by the MC68040.

I assume that I could have enabled interrupts during the initialization sequence
to allow static constructors to do interrupt-driven I/O. More generally, during
initialization, interrupts may be necessary. They will typically be required in
a multiprocessor configuration.

Joel, any comments on this last point?


Charles-Antoine Gauthier
Research Officer
Software Engineering Group
Institute for Information Technology
National Research Council of Canada
Ottawa, ON, Canada
K1A 0R6