Changes between Initial Version and Version 1 of Developer/Multilib

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

Tidy up after the move to this wiki.


  • Developer/Multilib

    v1 v1  
     1= Multilib RTEMS =
     3= Multilib RTEMS =
     6The ''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.
     7The 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.
     9The 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 -
     11  $ m68k-rtems-gcc -print-multi-lib
     12  .;
     13  m68000;@m68000
     14  m5200;@m5200
     15  m5206e;@m5206e
     16  m528x;@m528x
     17  m5307;@m5307
     18  m5407;@m5407
     19  mcpu32;@mcpu32
     20  m68040;@m68040
     21  m68060;@m68060
     22  msoft-float;@msoft-float
     24This output is not easy to read as it is designed for other tools or packages.
     26RTEMS 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].
     28BSP and CPU model specific portions of RTEMS (libcpu and libbsp) are built into the separate library ''librtemsbsp.a''.
     29= RTEMS Multilib Selections =
     32The 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.
     34Adding a new multilib variant only makes sense if -
     36 * 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'''".
     38 * GCC using an ISA not compatible to one already being present.
     40 * GCC using an optimization that is '''measurably''' superior than to others.
     42If one of these criteria is met then a new processor variant may be considered.
     44In 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.
     46On 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.
     47= [wiki:BuildCPUKit Building a CPU Kit] =
     50Building 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:
     52  * Control of RTEMS while allowing teams BSP flexibility.
     53  * Binary packages for 3rd party distributions.
     55The 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.
     57The command line to build a CPU Kit for the M68K target can be -
     59  $ ../rtems/configure --target=m68k-rtems \
     60                       --enable-multilib \
     61                       --enable-doc \
     62                       --enable-cxx \
     63                       --enable-posix \
     64                       --enable-networking \
     65                       --disable-tests \
     66                       --disable-itron
     68You will need to select the <tt>configure</tt> options that suite you. To build RTEMS enter -
     70  $ make RTEMS_BSP="" all install