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.172.129 with SMTP id l1mr15771755qaz.4.1374156562274; Thu, 18 Jul 2013 07:09:22 -0700 (PDT) X-Received: by 10.182.191.4 with SMTP id gu4mr125079obc.17.1374156562131; Thu, 18 Jul 2013 07:09:22 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!t19no1938243qam.0!news-out.google.com!dk8ni470qab.0!nntp.google.com!t19no2090506qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 18 Jul 2013 07:09:21 -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> <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Size optimization for objects From: "Rego, P." Injection-Date: Thu, 18 Jul 2013 14:09:22 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:16414 Date: 2013-07-18T07:09:21-07:00 List-Id: On Thursday, July 11, 2013 6:10:05 AM UTC-3, Niklas Holsti wrote: > (For the record, I understand from your preceding message that this is > the output of "nm --print-size --size-sort bla.exe".) Yes. > > 00414176 ffbec001 D ___gl_locking_policy > > 00414175 ffbec001 D ___gl_queuing_policy > > 00414174 ffbec001 D ___gl_task_dispatching_policy > > This is starting to look like a bug in your "nm". The three variables > above are clearly of size 1 octet (the addresses differ by 1 octet at > each step) but the "size" column is not 00000001. I agree. > An example where the size (of the first object) is evidently 2 octets > (I'm quoting these line pairs in address order, not in the original size > order): > > 00414b36 ffbec002 D _ada__exceptions__exception_traces__nlineXn > > 00414b38 ffbec004 D ___gnat_exception_actions_global_action > And 3 octets: > > 00414b41 ffbec003 D _system__stack_checking__multi_processor > > 00414b44 ffbec00c D _system__stack_checking__null_stack_info > And 4 octets: > > 00414b38 ffbec004 D ___gnat_exception_actions_global_action > > 00414b3c ffbec004 D ___gnat_exception_actions_initialized > In each case, in the "size" column, the last three hex digits show the > correct size, but the first five are "ffbec", clearly wrong for a size > value. Yes, it makes sense. > Sorting the whole listing into address order shows that the first five > hex digits of the "size" column behave in a systematic manner: the list > starts with 857 lines with "ffbff" in these digits, and all these > symbols are of type "t" or "T". The next line is type "D" and has > "ffbec" in these digits. I haven't tried to discover any rules for this, > since there is evidently a bug in your "nm", producing these incorrect > "size" values. I will try it with another version to see the results.