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.40.65 with SMTP id j1mr11811378qae.7.1373457446109; Wed, 10 Jul 2013 04:57:26 -0700 (PDT) X-Received: by 10.49.120.67 with SMTP id la3mr896583qeb.35.1373457446095; Wed, 10 Jul 2013 04:57:26 -0700 (PDT) Path: border1.nntp.ams.giganews.com!nntp.giganews.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!t19no1047989qam.0!news-out.google.com!f7ni1805qai.0!nntp.google.com!t19no1047988qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 Jul 2013 04:57:26 -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> <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com> Subject: Re: Size optimization for objects From: "Rego, P." Injection-Date: Wed, 10 Jul 2013 11:57:26 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 3658 Date: 2013-07-10T04:57:26-07:00 List-Id: > > 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? > > 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. Sorry, I meant "bla.txt". I agree, it was just a comment. > > 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. Again, if you consider the lots of things added by "ls -l", the size of bla.exe should be bigger. > 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. Since the output is big, I will paste it in the next post. > 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. I will run objdump so. Thanks. Rego. > -- > > Niklas Holsti > > Tidorum Ltd > > niklas holsti tidorum fi > > . @ .