comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Size optimization for objects
Date: Mon, 01 Jul 2013 21:21:18 +0300
Date: 2013-07-01T21:21:18+03:00	[thread overview]
Message-ID: <b3dvkvFni1uU1@mid.individual.net> (raw)
In-Reply-To: <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com>

On 13-07-01 19:35 , Rego, P. wrote:
> 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?

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

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".

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


  reply	other threads:[~2013-07-01 18:21 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 [this message]
2013-07-02 20:32           ` Rego, P.
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