Re: Size optimization for objects

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

On Monday, July 1, 2013 12:28:24 PM UTC-3, Niklas Holsti wrote:
> In the linker world, "symbol value" usually means the address of the
> object or subprogram identified by the symbol. However, sometimes
> symbols can also stand for other kinds of values (offsets or sizes), but
> that is less common.
Ok, now I understand. Thanks.

> My "nm", on my 64-bit system, generates the value/address as a single
> column with 16-digit hex values, followed by "D" and other codes in the
> second column. Perhaps your "nm" separates the 16 hex digits into two
> 8-digit groups, for easier reading? Are you using 32-bit or 64-bit binaries?
I am using 32-bit binaries. Actually, it generates 2 columns of 8 hex digits only when I put the options --print-sizes --size-sort. Otherwise, it gives me something like
02d62538 N .stab

When I put the option --print-size --size-sort, it gives me (in a big list)
02d62538 fd3c61e0 N .stab

so I wonder that the second column should be the size. However, if I add all those second columns, the sum result is incoherent (much much bigger) with the real size of the final binary. Maybe is it masked with something I am missing?


> 
> 
> 
> > Also, the second column represents the symbol size (in bytes I
> 
> > presume).
> 
> 
> 
> From your example, I doubt that: ff42d001 does not seem a likely size
> 
> for anything.
> 
> 
> 
> -- 
> 
> Niklas Holsti
> 
> Tidorum Ltd
> 
> niklas holsti tidorum fi
> 
>       .      @       .