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
X-Received: by 10.180.36.211 with SMTP id s19mr1938624wij.1.1374170232681;
 Thu, 18 Jul 2013 10:57:12 -0700 (PDT)
Path: 
 border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!cw2no28869508wib.0!news-out.google.com!b5ni66255wiz.1!nntp.google.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, 18 Jul 2013 20:57:11 +0300
Organization: Tidorum Ltd
Message-ID: <b4qojnFdcceU1@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>
 <b4791rF6i9hU1@mid.individual.net>
 <ca34e347-b53e-4119-b6d1-0cba6f40be79@googlegroups.com>
Mime-Version: 1.0
X-Trace: individual.net GBwWfwN2XrMuvyZIsffvRQb8LVYmFawfW51/2jQeihOr8YwAxs
Cancel-Lock: sha1:1rOVmL9kdkZbgPqyO7bhoEabAGM=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <ca34e347-b53e-4119-b6d1-0cba6f40be79@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Original-Bytes: 2950
Xref: number.nntp.dca.giganews.com comp.lang.ada:182577
Date: 2013-07-18T20:57:11+03:00
List-Id: <comp.lang.ada>

On 13-07-18 18:12 , Rego, P. wrote:
> On Thursday, July 11, 2013 5:35:06 AM UTC-3, Niklas Holsti wrote:
>> 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.
> Ok.
> 
>> 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
> Ok.
> 
> Interesting, I run the same code bla.adb on a Unix machine. The first
> part of the second column (that one which writes ffbec...), and it
> does not appear here.  So the lines look like 00000000 00000001 D
> ada__exceptions_E

That looks better.

> However when I add all the column, the result also seems incoherent,
> around 8GB.  The real bla.out generated is ~478kB.

If you send me the new "nm" output, I can have a look and try to
understand this 8 GB result. You can use the mail address given under
"Contact information" at http://www.tidorum.fi/en/index.html, or the
address that my signature below tries to obscure on two lines.

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