Re: libstdc++ libtool lossage

[Jakub Jelinek <jakub at redhat dot com>]

On Sun, Feb 24, 2002 at 06:19:14PM -0500, David Edelsohn wrote:
> >>>>> Jakub Jelinek writes:
> 
> Jakub> Show me a system where it doesn't matter.
> Jakub> Over 80% of shared libraries on typical Linux system are plain C shared
> Jakub> libraries. Having every such shared library linked against
> Jakub> libgcc_s.so means every program is linked against it.
> Jakub> I cannot imagine how you can manage to avoid a couple
> Jakub> of non-shareable dirty pages per every single process, a bunch of
> Jakub> system calls and relocation/symbol lookup costs per each
> Jakub> process just because of libgcc_s 
> Jakub> (which is usually not used at all, worst case some divide routine or
> Jakub> something (but those are usually already exported from glibc)).
> 
> 	Depending on libgcc.so does matter on all systems.  The question
> in my mind is the price relative to other performance impacts -- the
> startup cost versus the cost of the extra page frames and page table
> entries for divide, mod, and truncate routines duplicated in each
> executable and shared object.  That memory pressure and VM overhead has a
> cost when those routines are present in a large number of programs and
> libraries in the system.

See above where I wrote that on most linux
targets, the divide/mod/truncate are already exported from glibc, so the
second cost is zero.
If they are not exported from glibc, even then it is IMHO a win -
typical divide/mod/truncate routines are very small compared
to whole libgcc_s.so, and typically consist of code only (so are shareable).

	Jakub