sparc-rtems-size

[gregory.menke at gsfc.nasa.gov]

Fabio Degiovanni - Eicas writes:
 > I have two another questions, probably trivial questions but I am new at 
 > this things:

 > -why is the dimension of the executable code far bigger then the text 
 > dimension given by sparc-rtems-size? It's also bigger then the code+data 
 > dimension given by sparc-rtems-size. What's the meaning of the 
 > executable dimension?

The final output file can consist of lots of extra stuff.  Certainly
.text, .data and .bss are all there, but debug data can be there as
well.  It also depends on the format of the output (binary, elf, s3r,
etc...), and if some sections are stripped out or not.  If you use
sparc-rtems-objcopy to generate a simple binary file from your
executable, stripping out the .bss and debug related sections, it will
end up being pretty close to what the size program gives you.

You can exercise a lot of control over the output file by manipulating
the contents of the link command file  which I touch on below;
changing the relative order of sections is possible, as is creating
symbols at various points in the linked image to help it relocate
itself, etc..


 > -why are the sectons .text .data and .bss evaluated using 
 > sparc-rtems-size on the object far smaller then the .text .data and .bss 
 > evaluated using sparc-rtems-size on the executable? I think  this is due 
 > to the linking of my object with the rtems libraries to produce the 
 > executable. What are the rtems libraries that are linked with my code?

You are correct.  In the tree where RTEMS is installed, execute

find . -name "*.a"

and you'll see the libraries.  Its probably worth searching around
down in those directories because thats where all the RTEMS-related
#include files are, as well as the gcc configuration parameters (we
call them bsp_specs) and the linker command file as well.  This tree
is generated by the RTEMS build & installation process.  The standard
C includes (and the standard C libary) are coming from the installed
gcc (sparc-rtems-gcc, in your case), so you will not find them in the
same place as the RTEMS files.

If you build RTEMS for multiple targets, you'll end up with parallel
trees, one per target.  The structure is consistent, so its easy to
set up a makefile that can build the same program for different RTEMS
targets (assuming the software doesn't exploit bsp-specific features),
and switch between the builds by changing 1 environment variable.

Gregm