comp.lang.ada
 help / color / mirror / Atom feed
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.



  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