Fabio Degiovanni - Eicas
degiovanni at eicas.it
Tue Sep 9 12:36:22 UTC 2003
Dear Joel Sherrill,
using the tool sparc-rtems-nm
--size-sort --extern-only I resolved my problem: I found out the name of
one of my variable whose dimension where incorrect. I didn't know that
tool, where can I find a manual o a list of these useful commands?
I realised that calling sparc-rtems-size on an object file is not
correct: it seems that the bss section is not computed correctly:
I wrote this simple example:
I saw correctly 4Mb in the bss section calling sparc-rtems-size on the
executable, but calling it on the object I saw 0 bytes in the bss section.
Defining a as an initialised variable I saw 4Mb both calling
sparc-rtems-size on the executable and calling it on the object in the
Thank you very much
Joel Sherrill wrote:
> Fabio Degiovanni - Eicas wrote:
>> Thank you very much for your help, I appreciated it very much.
>> I need to solve compleatly the problem, so I have some more questions:
>> -you told me that most likely the .bss section is not included in the
>> output image. I presume that this happen always because the
>> uninitialised data are created run-time. Am I right?
> Since it is uninitialized variables, it is really just reserved space
> in memory which is reserved in the linker script.
> I have also seen linker scripts with minor errors which resulted in
> extra large bss sizes being reported. Is
> your linker script in the primary tree or custom?
>> -you told me that I must have some huge arrays declared in that code,
>> but I presumed that my bss section would have been much smaller. I
>> tried to do sparc-rtems-size to every object files and than I summed
>> up and I found:
>> text data bss dec hex
>> 117506 181240 4816 303562 4a1ca
>> Is the difference between the object files size and executable file
>> only due to the static linking of rtems libraries? In this case it
>> seems that the umount of uninitilalised data is introduced by the
>> rtems libraries. What's the difference between doing sparc-rtems-size
>> on the executable and on the object files?
> The libraries just like you think. I don't think there is 9806288 -
> 4816 in uninitialized data in
> any of the libraries. You are only pulling in about another 100K of
> code but getting 9.4 MB
> of data.
> I think there might be a linker script file mistake in this case.
> Which one are you using?
> Also look at the symbol table sorted by size (sparc-rtems-nm
> --size-sort --extern-only)
> and see what's so big.
>> Thank you very much
>> Fabio Degiovanni
>> Joel Sherrill wrote:
>>> gregory.menke at gsfc.nasa.gov wrote:
>>>> Fabio Degiovanni - Eicas writes:
>>>> > Dear Sirs,
>>>> > 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.
>>>> Most likely the .bss section is not included in the output image.
>>> Correct. And yikes!! You must have some huge arrays declared in
>>> that code.
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