sparc-rtems-size

[Joel Sherrill]

Fabio Degiovanni - Eicas wrote:

> 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?

"ls /opt/rtems/bin" and then do man/info on each of the commands.
Seriously, there are a lot of commands and useful options.  I didn't
even know you could sort by size until I looked this one up this
morning. :)

I find the following useful to know when hunting an object sizing
issue.

   + size
   + nm -v (sort by address)
   + nm --sort-size
   + ld -Map (show why .o's are pulled in)


> 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:
> 
> int a[1000000];
> 
> int main(){
> 
> return;
> }
> 
> 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.

It is doing this natively on Linux so I don't know if this is a bug
or feature.

> 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 
> data section.

Watchign size is important on embedded targets. :)

> Thank you very much
> 
> Fabio Degiovanni
> 
>                               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.
>>
>> --joel
>>
>>
>>>
>>> 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.
>>>>
>>>>> Gregm
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985