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.54.73 with SMTP id p9mr16027759qag.1.1374160335471;
        Thu, 18 Jul 2013 08:12:15 -0700 (PDT)
X-Received: by 10.49.4.136 with SMTP id k8mr574811qek.19.1374160335447; Thu,
 18 Jul 2013 08:12:15 -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!news.bbs-scene.org!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!t19no1944260qam.0!news-out.google.com!dk8ni470qab.0!nntp.google.com!t19no2097410qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 18 Jul 2013 08:12:15 -0700 (PDT)
In-Reply-To: <b4791rF6i9hU1@mid.individual.net>
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>
 <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ca34e347-b53e-4119-b6d1-0cba6f40be79@googlegroups.com>
Subject: Re: Size optimization for objects
From: "Rego, P." <pvrego@gmail.com>
Injection-Date: Thu, 18 Jul 2013 15:12:15 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:16416
Date: 2013-07-18T08:12:15-07:00
List-Id: <comp.lang.ada>

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

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