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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.2.137 with SMTP id 9mr17288087qaj.2.1372797130064; Tue, 02 Jul 2013 13:32:10 -0700 (PDT) X-Received: by 10.49.64.136 with SMTP id o8mr867079qes.32.1372797130051; Tue, 02 Jul 2013 13:32:10 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!y2no156192qax.0!news-out.google.com!f7ni623qai.0!nntp.google.com!y2no156183qax.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 2 Jul 2013 13:32:09 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=189.77.226.1; posting-account=TRgI1QoAAABSsYi-ox3Pi6N-JEKKU0cu NNTP-Posting-Host: 189.77.226.1 References: <9cbe0ad4-f54c-4c99-ba58-4db027ae962e@googlegroups.com> <70b1d2b0-d5ab-431e-84b9-9f00af08dbe2@googlegroups.com> <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> Subject: Re: Size optimization for objects From: "Rego, P." Injection-Date: Tue, 02 Jul 2013 20:32:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Original-Bytes: 3510 Xref: number.nntp.dca.giganews.com comp.lang.ada:182234 Date: 2013-07-02T13:32:09-07:00 List-Id: > 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.