Re: The future of __main (was Re: __main call for c++ on sparc-elftarget)

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Chris" == Chris Lattner <sabre@nondot.org> writes:

 Chris> Jim Wilson wrote:
 >> __main is archaic. ELF systems use the .init/.fini sections to run
 >> static construtors/destructors. crti.o defines function prologues
 >> for init/fini, crtn.o defines function epilogues, crt0.o branches
 >> to the init function at startup, and registers passes the fini
 >> function to atexit.
 Chris> ...

 >> Some of the older embedded ELF targets aren't using .init/.fini
 >> yet, but should be fixed to do so. Perhaps sparc-elf is one of
 >> them? It could be broken from lack of maintenance.

 Chris> I just wanted to say that I hope that __main never goes away:
 Chris> it is a great way to expose the information about static ctors
 Chris> and dtors to the compiler, which the "magic" .init/.fini
 Chris> sections doen't do as well.  In particular, for most C
 Chris> programs (those which don't ctor or dtors), the LLVM compiler
 Chris> is able to completely eliminate the overhead of the
 Chris> _possibility_ of having ctors and dtors (general DCE
 Chris> algorithms just delete the code automatically), which leaves
 Chris> __main empty for codes where it is safe.

 Chris> I don't see how to implement this important size optimization
 Chris> using crt0.o and .init/.fini.  Will support for __main stay
 Chris> around forever, or should I be looking for alternatives?  I
 Chris> would really like to avoid having to put in special purpose
 Chris> code to handle this optimization.

I don't understand what important size optimization you're talking
about here.  If a particular program has no constructors/destructors,
I would hope the compiler and/or linker could eliminate the code that
deals with them from .init just as well.  Perhaps they don't currently
do that, but that doesn't mean hanging on to the obsolete mechanism is
a good idea.  (In any case, aren't we talking about a few words here?)

More importantly, the old mechanism is completely broken for an
important case: it doesn't cope with shared libraries that contain
static objects that need construction or destructing.  One of my
colleagues recently wasted a lot of time on this.  Clearly, since
there is no "main" in a library, a mechanism based on main calling
__main doesn't work.  But .init sections do.  Now if only my toolchain
and shared lib loader used them, we'd be all set... (yes, I know,
upgrade it... trying...)

	paul