Changes between Initial Version and Version 1 of Developer/Multilib

Timestamp:

08/09/05 14:00:21 (19 years ago)

Author:

ChrisJohns

Comment:

Tidy up after the move to this wiki.

Developer/Multilib

@@ +1 @@
+= Multilib RTEMS =
+
+= Multilib RTEMS =
+
+
+The ''multilib'' process supports building a set of related libraries for a given target where the individual libraries in the set use different specific compiler flags (such as flags for code generation options, pre-processor defines, etc) for the individual libraries.
+The reason this is needed can be seen by examining the M68K GCC compiler.  That compiler generates code for a number of processor variants in the M68K family, for example, it can generate code for the original 68000, the 68040 or a 528x Coldfire. These processors all use a closely related instruction set, but processor differences mean code compiled for one may not run on another. GCC provides a special library called ''libgcc.a'' that holds intrinsic functions needed by the compiler. These intrinsic functions provide "software instructions" (such as non-basic math support routines) that the processor may not support.   However, which functions GCC considers to be intrinsic should be able to vary within a processor family.   One processor variant will have hardware floating point and another processor variant will not, and GCC (and RTEMS) should be able to generate efficient code for each processor variant. When we wish to have different code for a range of related yet potentially incompatible processors in a family by providing multiple related libraries we use the '''multilib''' process.
+
+The multilib process extends beyond ''libgcc.a'' to ''libc.a'', ''libm.a'', and ''libstd++.a''. An RTEMS tool set will provide each of these libraries for each of the processor variants that GCC supports. You can see the multilib information by invoking gcc with the option '-print-multi-lib'. The output for the M68K tool chain is -
+
+  $ m68k-rtems-gcc -print-multi-lib
+  .;
+  m68000;@m68000
+  m5200;@m5200
+  m5206e;@m5206e
+  m528x;@m528x
+  m5307;@m5307
+  m5407;@m5407
+  mcpu32;@mcpu32
+  m68040;@m68040
+  m68060;@m68060
+  msoft-float;@msoft-float
+
+This output is not easy to read as it is designed for other tools or packages.
+
+RTEMS core under the ''cpukit'' source tree does not reference any BSP specific details. This allows it to be built as a set of multiple libraries named ''librtemscpu.a''. A configure command line option will build a multilib RTEMS as shown in [wiki:#BuildCPUKit Building a CPU Kit].
+
+BSP and CPU model specific portions of RTEMS (libcpu and libbsp) are built into the separate library ''librtemsbsp.a''.
+= RTEMS Multilib Selections =
+
+
+The range of variants a specific tool set creates can vary for the same processor family. For example a build of the M68K tool set for '''m68k-elf''' can create a different variant set compared to the RTEMS tool set built with '''m68k-rtems'''. RTEMS tries to keep the number of libraries built to a minimum to keep the build time down, the amount of disk space used, and avoid a variant explosion that could result if a specific processor has a large number of variants. The Coldfire is a good example of this.
+
+Adding a new multilib variant only makes sense if -
+
+ * Some code is being compiled specifically for a specific variant. An example would be newlib, libgcc or RTEMS/cpukit containing code conditionally being compiled upon a specific processor, ie for the Coldfire family of processors "#ifdef '''mcf528x'''".
+
+ * GCC using an ISA not compatible to one already being present.
+
+ * GCC using an optimization that is '''measurably''' superior than to others.
+
+If one of these criteria is met then a new processor variant may be considered.
+
+In some legitimate cases, RTEMS needs to know information about a specific CPU model which is beyond the multilib variations.  This may be due to issues such as cache size, peripherals on the CPU itself, or interrupt vectoring specifics.  In these cases, the code in question should be placed in the libcpu or libbsp source where the specific CPU model is available for use.
+
+On some ports, code that is normally found under cpukit/score/cpu is placed under libcpu or libbsp/CPU/shared because it requires knowing the specific CPU model to properly implement.  This is an unfortunate fact of life which makes it hard to find source sometimes.
+= [wiki:BuildCPUKit Building a CPU Kit] =
+
+
+Building a CPU Kit for a specific tool chain results in RTEMS being built for each one of the processor variants supported by the tool chain. This will increase the time it takes to build RTEMS, but does mean RTEMS will not need to be built for the tool chain again regardless of the number of board support packages to be built. This is not suitable for the development and maintance of RTEMS. It does help:
+
+  * Control of RTEMS while allowing teams BSP flexibility.
+  * Binary packages for 3rd party distributions.
+
+The BSP can be a separate package, and therefore a library, or it can be built into the application. There is little difference between either BSP code base. The issues are more related to configuration control.
+
+The command line to build a CPU Kit for the M68K target can be -
+
+  $ ../rtems/configure --target=m68k-rtems \
+                       --enable-multilib \
+                       --enable-doc \
+                       --enable-cxx \
+                       --enable-posix \
+                       --enable-networking \
+                       --disable-tests \
+                       --disable-itron
+
+You will need to select the <tt>configure</tt> options that suite you. To build RTEMS enter -
+
+  $ make RTEMS_BSP="" all install