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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!news.swapon.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: Sat, 06 Jul 2013 19:06:43 +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> <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net h8/1oevtAwIqecCReM2F0QbeqPoqwaQl0U7GVPYtSvGO89diOe Cancel-Lock: sha1:CT6A3rz8LXlZZV/ppR1cNMm/n/0= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> Xref: news.eternal-september.org comp.lang.ada:16128 Date: 2013-07-06T19:06:43+03:00 List-Id: On 13-07-02 23:32 , Rego, P. wrote: >> 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 Looks about right to me. > > and the read size of bla.o is 611 bytes. What do you mean by "read size"? Perhaps this is a typo, and you meant to write "real size"? If you mean the total size of the file bla.o (from the directory listing, e.g "ls -l"), this is not a useful comparison, because the file contains much more data than just the machine code: there are headers, symbol tables, and other debug information -- among other things, the information that "nm" uses to associate machine code addresses with identifier symbols. > 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, What do you mean by "bla.parse"? Perhaps "bla.txt"? The size of this text file is totally irrelevant. > 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. Again, if by "real size" you mean the entire size of the file bla.exe, the comparison it not useful, just as for bla.o: bla.exe contains a lot more data than just the machine code. The Excel summed size that you show is surprising. Perhaps the method "nm" uses to compute function size (as the difference between to adjacent symbols) does not work correctly for some special case, such as the function with the highest address. Without seeing the whole output from "nm", it is difficult to say. To find the total amount of data/code, in an exe, I would look either at the link map output, or use "objdump" to see the sizes of the segments. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .