sparc-rtems-size

[Fabio Degiovanni - Eicas]

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:

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.

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.

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


-- 
Dott. Ing. Degiovanni Fabio
Eicas Automazione
Via Vincenzo Vela, 27 10128 Torino (ITALIA)
Telefoni +39-11-562.37.98/562.3088 Fax +39-11-436.06.79