Re: Trivial program size inflation

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, Jul 02, 2023 at 06:52:55PM -0400, Mouse wrote:
> > 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.

There is no way to trigger GC of code based on the presence of certain
sections or relocation types. That rules out dropping code to handle
ifunc, global constructors, destructors as well as the TLS code. Making
the PIE support conditional would be possible, but IMO is not worth the
effort. The amount of code you get for pthread init again is so small,
not worth the effort.

Joerg