From: "Rego, P." <pvrego@gmail.com>
Subject: Re: Size optimization for objects
Date: Tue, 2 Jul 2013 13:32:09 -0700 (PDT)
Date: 2013-07-02T13:32:09-07:00 [thread overview]
Message-ID: <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> (raw)
In-Reply-To: <b3dvkvFni1uU1@mid.individual.net>
> 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
and the read size of bla.o is 611 bytes. 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, 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.
next prev parent reply other threads:[~2013-07-02 20:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 19:49 Size optimization for objects Rego, P.
2013-06-29 7:10 ` Georg Bauhaus
2013-07-01 13:56 ` Rego, P.
2013-07-01 16:49 ` G.B.
2013-06-29 9:48 ` Jack Daniels
2013-07-01 13:58 ` Rego, P.
2013-06-30 11:34 ` rrr.eee.27
2013-07-01 14:35 ` Rego, P.
2013-07-01 15:28 ` Niklas Holsti
2013-07-01 16:35 ` Rego, P.
2013-07-01 18:21 ` Niklas Holsti
2013-07-02 20:32 ` Rego, P. [this message]
2013-07-06 16:06 ` Niklas Holsti
2013-07-10 11:57 ` Rego, P.
2013-07-10 11:58 ` Rego, P.
2013-07-11 9:10 ` Niklas Holsti
2013-07-18 14:09 ` Rego, P.
2013-07-18 14:10 ` Rego, P.
2013-07-11 8:35 ` Niklas Holsti
2013-07-12 0:35 ` Randy Brukardt
2013-07-18 15:16 ` Rego, P.
2013-07-18 15:12 ` Rego, P.
2013-07-18 17:57 ` Niklas Holsti
2013-07-19 5:02 ` Randy Brukardt
2013-07-19 13:20 ` Eryndlia Mavourneen
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox