This is the mail archive of the
mailing list for the GCC project.
Re: Exception handling, dynamic linking and weak symbol tricks
- To: egcs at cygnus dot com
- Subject: Re: Exception handling, dynamic linking and weak symbol tricks
- From: "Melissa O'Neill" <oneill at cs dot sfu dot ca>
- Date: Wed, 16 Sep 1998 23:09:02 -0700
- cc: Mike Stump <mrs at wrs dot com>
- References: <199809162354.QAA00720@kankakee.wrs.com>
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
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...