Re: Exception handling, dynamic linking and weak symbol tricks

["Melissa O'Neill" <oneill at cs dot sfu dot ca>]

Apparently exasperated at my vagueness, Mike Stump wrote:
> [...]  Please just state your worries, and have them confirmed or have
> it explained to you why it will work. Try using routine names, try
> explaining the scenario.  Try explaining _why_ you think it won't
> work.

Okay. When collect2 is responsible for sorting out constructors,
destructors and exception handler frames, it does so through a two global
tables named __DTOR_LIST__ and __CTOR_LIST__, which are executed by libgcc's
__do_global_ctors (which is called by __main) and __do_global_dtors
(which is called during exit() cleanup). Since __DTOR_LIST__ and
__CTOR_LIST__ are global symbols, there can't be multiple tables. This
means that dynamically loaded modules won't have any static
constructors/destructors run. Thus even if the library includes its own
reg_frame() and dereg_frame() routines and its own frame_table, they
aren't going to be called.

(And with the way collect2 works right now, if the loaded module does
include reg_frame and dereg_frame, it'll also have a have a __CTOR_LIST__
and a __DTOR_LIST__, causing a dynamic-link-time symbol clash.)

I'd imagine that when a recent GNU linker handles constructors and
exception frame tables, and when dynamic loading of modules is handled
by a similarly functioned runtime linker, there wouldn't be a problem.

Hope this helps explain things...

    Melissa.