From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!news.snarked.org!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Size optimization for objects Date: Mon, 01 Jul 2013 21:21:18 +0300 Organization: Tidorum Ltd Message-ID: References: <9cbe0ad4-f54c-4c99-ba58-4db027ae962e@googlegroups.com> <70b1d2b0-d5ab-431e-84b9-9f00af08dbe2@googlegroups.com> <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 4eelY3HDNjysOEvpfh/FVAZ4seYk2Iy0kMCjz7UAAiYLuxoBZg Cancel-Lock: sha1:ayMEaZpAuxyhXQPdkPHcLhdjk0k= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com> X-Original-Bytes: 3705 Xref: number.nntp.dca.giganews.com comp.lang.ada:182191 Date: 2013-07-01T21:21:18+03:00 List-Id: 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 . @ .