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!nx01.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit3.readnews.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Size optimization for objects
Date: Thu, 11 Jul 2013 11:10:05 +0200
Organization: Tidorum Ltd
Message-ID: <b47b3dF6vrtU1@mid.individual.net>
References: <9cbe0ad4-f54c-4c99-ba58-4db027ae962e@googlegroups.com>
 <70b1d2b0-d5ab-431e-84b9-9f00af08dbe2@googlegroups.com>
 <b0586a20-1c93-49ad-b4c5-0a19f6288371@googlegroups.com>
 <b3dlgoFla32U1@mid.individual.net>
 <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com>
 <b3dvkvFni1uU1@mid.individual.net>
 <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com>
 <b3qtkjFhc0tU1@mid.individual.net>
 <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com>
 <a15df517-37ed-46d4-bf2f-1268076b49c8@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net Mu4hLRJRaY4JHq94IVzaMAXPGgAC5kxuxC+P/Vr+rAvya/snLg
Cancel-Lock: sha1:leKgIXm+ZEsfoIKAAVpsRskLgOI=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <a15df517-37ed-46d4-bf2f-1268076b49c8@googlegroups.com>
X-Original-Bytes: 3140
Xref: number.nntp.dca.giganews.com comp.lang.ada:182458
Date: 2013-07-11T11:10:05+02:00
List-Id: <comp.lang.ada>

On 13-07-10 13:58 , Rego, P. wrote:
> Output "bla.txt" of nm:

(For the record, I understand from your preceding message that this is
the output of "nm --print-size --size-sort bla.exe".)

> 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.

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.

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .