Re: Size optimization for objects

["Rego, P." <pvrego@gmail.com>]

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.