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!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder02.blueworldhosting.com!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: Thu, 11 Jul 2013 10:35:06 +0200 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> <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net EThbO6dPAdCTm4Bf/J0eTQcwjSESEw9l+50UvKvp9xJGLazRwx Cancel-Lock: sha1:DG1s3TJYzWfExPdONYae5uGAPMI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com> X-Original-Bytes: 3185 Xref: number.nntp.dca.giganews.com comp.lang.ada:182457 Date: 2013-07-11T10:35:06+02:00 List-Id: On 13-07-10 13:57 , Rego, P. wrote: >>> 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. > > Yes, it is from directory listing. In this case, the 'size' provided > by "ls -l" should be bigger, right? Yes, if you consider only the size of the code ("text" segment). For data, if the program contains uninitialized, statically allocated variables, the file size can be smaller than the "memory image" size, because the .o file only describes those variables (name, size, address or offset) but does not provide values for the variables. >>> Also, if I run >>> nm --print-size --size-sort bla.exe > bla.txt ... >>> 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. > I don't think 8.61147E+12 is irrelevant. The fact that this number is so absurdly large is relevant, and the fact that it is larger than the size of the .o file may be relevant, unless the number includes the size of uninitialized statically allocated data -- see above. Continued in reply to your next message... -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .