Re: Size optimization for objects

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 13-07-02 23:32 , Rego, P. wrote:
>> On a 32-bit system (i686, Ubuntu) "nm --print-size --size-sort", gives
>> me output with a second column that does look like a size, for example:
>> 40301408 0000003c T Handle_TMs
>> 40301308 0000003c T Slot_Start_ISR
>> 4030cd14 0000003c T XM_read_console
>> 4030ccd8 0000003c T XM_write_console
>> 4030ec60 0000003c T _TOD_Handler_initialization
>> 40311d90 0000003c T _Timer_Manager_initialization
>> 403106ac 0000003c T _User_extensions_Add_API_set
>> 40302dac 0000003c T ecs_Populate_Synchronization_Message
>> 40305294 0000003c T efw_Pool_Is_Valid
>> 403071b4 0000003c T emb_Max_RT_To_BC_Transfer_Duration
>> 4030d83c 00000040 T Clock_driver_support_initialize_hardware
>> 403026c4 00000040 T Time_Span_Max
> That's the same with me. 
> 
>> Running with --numeric-sort instead of --size-sort show that the "size"
>> is indeed computed as the difference between the address of the symbol
>> and the address of the symbol with the next higher address, as "man nm"
>> says.m
>> Perhaps you can show a bit more of your nm output? Could give us more
>> basis for guessing what the second column might mean, if it is not "size".

> Actually, the only point it that, when I add all the second column values,
> the resulting value is totally different from the real binary size.
> 
> Trying a simple example.
> 
>   -- bla.adb
>   with Ada.Text_IO;
>   procedure Bla is
>     procedure Write_Something is
>     begin
> 	Ada.Text_IO.Put_Line ("just a test");
>     end Write_Something;
>   begin
>     	Write_Something;
>   end Bla;
> 
> and building it with gnatmake bla.adb.
> 
> If I run 
>    nm --print-size --size-sort bla.o
> 
> the console returns me
> 
> 00000000 00000014 r .rdata
> 00000022 0000001e T __ada_bla
> 00000000 00000022 t _bla__write_something.0

Looks about right to me.
> 
> and the read size of bla.o is 611 bytes.

What do you mean by "read size"? Perhaps this is a typo, and you meant
to write "real size"?

If you mean the total size of the file bla.o (from the directory
listing, e.g "ls -l"), this is not a useful comparison, because the file
contains much more data than just the machine code: there are headers,
symbol tables, and other debug information -- among other things, the
information that "nm" uses to associate machine code addresses with
identifier symbols.

> If I add the second values,
> the total result is 16#44" which is 68 in decimal, which is not 611 bytes.
> 
> Also, if I run 
>    nm --print-size --size-sort bla.exe > bla.txt
> 
> the bla.parse is big,

What do you mean by "bla.parse"? Perhaps "bla.txt"? The size of this
text file is totally irrelevant.

> but adding the second column, the result (in Excel I convert it
> to decimal before adding) is 8.61147E+12 and the real bla.exe
> size is 1512500 bytes, also very different.

Again, if by "real size" you mean the entire size of the file bla.exe,
the comparison it not useful, just as for bla.o: bla.exe contains a lot
more data than just the machine code.

The Excel summed size that you show is surprising. Perhaps the method
"nm" uses to compute function size (as the difference between to
adjacent symbols) does not work correctly for some special case, such as
the function with the highest address. Without seeing the whole output
from "nm", it is difficult to say.

To find the total amount of data/code, in an exe, I would look either at
the link map output, or use "objdump" to see the sizes of the segments.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .