Fabio Degiovanni - Eicas
degiovanni at eicas.it
Mon Sep 8 15:53:46 UTC 2003
thank you very much for your answer, you have to
apologize me, but I mistook the question. What happens to me is that the
executable is smaller than what sparc-rtems-size returns.
To explain better:
-ls -l HISA returns 1869954
-sparc-rtems-size HISA returns
text data bss dec hex filename
231488 183040 9806288 10220816 9bf510 HISA
I understood well your explanation about the possibility that the output
file is bigger than the sum of the .text, .data and .bss sections, but I
cannot understand why my output file is smaller than the sum of the
.text, .data and .bss sections.
Thank you very much for help
gregory.menke at gsfc.nasa.gov wrote:
>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
> > -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.
Dott. Ing. Degiovanni Fabio
Via Vincenzo Vela, 27 10128 Torino (ITALIA)
Telefoni +39-11-562.37.98/562.3088 Fax +39-11-436.06.79
More information about the users