Re: Trivial program size inflation

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The CSU code has pretty much no idea on what the rest of the world is
> going to do.  It does: [...]

> There is no way with ELF to decide at link time which of those
> features are used by the program and therefore no way to remove any
> of them.

I don't think that's true.

If the program dynamically loads code, yes, it's true (or close
enough).  But, for a statically linked program (as pointed out
upthread, dlopen doesn't work when linked static), it can be done, and
with quite low otherwise-useless overhead.

Using pthreads as an example, consider this.  All pthreads .o modules
refer to (not "call") a specific function.  For concreteness, let's
call it _pthreads_csu_init.  _pthreads_csu_init is off in its own file;
that routine does the CSU initialization for pthreads.  The CSU code
makes a weak reference to _pthreads_csu_init, calling it only if the
weak reference was satisfied by a real definition.

Of course the dynamically-linked form of pthreads would always define
_pthreads_csu_init - or, alternatively, dynamic linking would use a
different CSU, one which unconditionally calls _pthreads_csu_init as an
ordinary reference.

Is it worth doing?  That's a separate question.  But I have no real
doubt that it could be done if desired.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B