Re: Size optimization for objects

["Rego, P." <pvrego@gmail.com>]

Hello Rolf,

On Sunday, June 30, 2013 8:34:30 AM UTC-3, rrr.e...@gmail.com wrote:
> strip(1) reduces the size of an application in the file system by removing the debug info.
So it's not the best option, because I am trying to reduce the application size in order to be able to debug the app. A new added code caused the app to grow beyond I expected, so now I am not able to debug it anymore. I think the best is to analyse using nm. But also probably there is more code (than the newest added one) I should optimize.
 
> If you want to see the size of various elements in a binary use nm(1). nm --print-size --size-sort might give you some hints where to start remving elements.
I am still having some difficult in understand the information generated by nm. It generates something like
00c038d6 ff42d001 D ___gl_locking_policy

The first column I think it's the "symbol value", the second column I guess it's the size of the symbol. The other columns are ok, since the man nm explains quite well. What does "symbol value" mean? 

Also, the second column represents the symbol size (in bytes I presume). If I sum all the symbol sizes, should the total sum give the size of the executable file? I tried this, but the total sum is far bigger than the real size of the application binary.

> If you compile with -fdata-sections -ffunction-sections and link with --gc-sections the linker automatically removes all unused code and all unused data. That is typically easier than gnatelim.
I also will try this. 

Thanks,
Rego.