Re: exceptions without libstdc++

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <4.2.0.58.20000614125738.00dee3e0@popmail.ucsd.edu>,
Erik Smith <ersmith@ucsd.edu> writes:

> Loren - thanks for taking the time to try to explain some issues. Apologies 
> for posting to the wrong list.  If I may, I would like to try to clear up 
> my lack of understanding of code size issues a bit more.  A few more questions:

> - For statically linked code, I thought the size of the text image on disk 
> (as indicated by size)  is the same size it would occupy in memory. Why 
> wouldn't this be true?

I'm not an expert by any means, but I think you are basically right
for most modern architectures.  Unmentioned detail: The text segment
size in core will be rounded up to, at least, the OS page size, but
that should be the only expansion on most modern architectures.

In general, memory footprint for static executables on modern UNIX
equals text + data + bss + stack (max. usage) + heap (max. usage).  As
explained above with the text segment, each segment size is rounded
to, at least, the OS page size before being added together to get the
total memory footprint.  Some people would also include per-process
memory required by the OS to support VM tables, etc.  But it is very
hard to talk about that in the general case.

> - My assumption is that any app that is compiled with dynamic linking will 
> load the shared libraries immediately at runtime (and not on demand).  So 
> the memory footprint should be equivalent to the static case. Is that right?

Not strictly true.  There are (at least) two issues:

When your application is statically linked, it only gets the object
files from the library that contain symbols that it actually uses.
Also, state of the art linkers [1] can actually pull in only those
sections needed from the library [2].  So under your assumption of
immediate load not demand load, the memory footprint could be higher
with dynamically linked executables verses static linked.

OTOH, if some other application has already loaded the shared library,
it might not affect your memory footprint at all (assuming you charge
the memory against the first application that opened it).

[1] GNU ld 2.10 can only do it for three ELF-based architectures.
[2] With special switches, gcc knows how to put one function or data
    element per section under ELF and other object formats to work
    with such linkers.

> - In your -static test you got the same sizes even though you excluded the 
> libstdc++ in the first one.  

Yup, since your application uses no symbols from libstdc++, under a
static link, they are not pulled in even though the library is
mentioned on the ld command line (either explicitly or, as in this
case, constructed by the gcc driver).

> I don't understand this: what is taking up 
> roughly 48K of text if not libstc++.

C++ exception machinery from libgcc.a is some.  That machinery uses
some symbols from libc (malloc, etc) . Thus, also any of libc needed
to satisfy all those symbols.  Some of libc uses symbols from other
parts of libc.  Thus, you get those parts too.

Compile:

int main()
{
  throw 1;
}

run nm on the executable.

Comment out 'throw 1'.  Compile and run nm again.  Notice all that
libc junk that got pulled in.

> What's worse is that on my system I 
> get equal sizes for (using -nodefaultlibs vs. not) except that my text size 
> is around 206K (g++ 2.95.2, RH 6.0): don't know why.

Yup, I see 216K on RH6.2 with g++ 2.95.1. ;-)

I know why.  FreeBSD's libc (which is what I use) has a much smaller
footprint than Linux's glibc.  I suppose it would be inappropriate use
of a GNU list to invite you to join the dark side... ;-)

> - The original motivation was to try to understand how the use of libraries 
> and language features affect code size and performance (smaller code has a 
> higher cache hit rate).  Maybe what matters is not the size of the text 
> segment but what code gets executed in that segment.  I'm not sure.   So 
> for instance is the performance of a 2K and 2M executable comparable if the 
> same code gets executed in each?  If so, I wouldn't have to worry about 
> what library code I include : just what I use.

OK, if you ever figure this out, you might want to contribute to GNU
ld. ;-)  I tend to believe that you are on a better track near the end
of that paragraph not the top.

Regards,
Loren