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.36.15 with SMTP id r15mr16084872qad.8.1374160572889; Thu, 18 Jul 2013 08:16:12 -0700 (PDT) X-Received: by 10.49.11.140 with SMTP id q12mr572656qeb.9.1374160572868; Thu, 18 Jul 2013 08:16:12 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!t19no2097926qam.0!news-out.google.com!dk8ni470qab.0!nntp.google.com!t19no2097921qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 18 Jul 2013 08:16:12 -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: <682e0154-06ed-47a9-8cd8-f7d71bd31f6a@googlegroups.com> Subject: Re: Size optimization for objects From: "Rego, P." Injection-Date: Thu, 18 Jul 2013 15:16:12 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Original-Bytes: 3412 Xref: number.nntp.dca.giganews.com comp.lang.ada:182576 Date: 2013-07-18T08:16:12-07:00 List-Id: On Thursday, July 11, 2013 9:35:23 PM UTC-3, Randy Brukardt wrote: > To provide a bit more background: the size of an .o file is correlated to > the associated code size, but it (probably) has no relation to the data size > at all. > > (I'm going to explain how Janus/Ada and some ancient C compilers handled > these files; I would expect GCC and GNAT to be similar, but I don't know for > certain.) > .o files have a bunch headers and typcially three segments: .text (which > contains code), .data (which contains *initialized* data), and .bss (which > contains *uninitialized* data). There is also some relocation information > for the code, so the .o file is generally quite a bit larger than contained > code alone. > For Janus/Ada, we put values of *constants* (string literals, float > literals, static aggregates, etc.) into the .data segment, but not any > variables. Those all go into the .bss segment. (We did that to support > putting the code and constants into EEPROM; the data (in the .bss) is the > only part that has to be mapped to RAM.) > The .data segment is also present in its entirety in the .o file (it has to > be, in order to have those initial values). But the .bss segment is just a > header specifying it's size; it has no contents at all and thus contributes > almost nothing to the size of the .o file. > So for Janus/Ada, an .o file is code size + constants size + headers. The > data size doesn't have any impact on the .o file size at all. It's possible > that GNAT might put some initialized things into the ".data", but I highly > doubt it would do that for anything that is really uninitialized. > Hope this clarifies things. Certaintly it clarifies, thanks Randy.