Exception handling, dynamic linking and weak symbol tricks

Mike Stump mrs@wrs.com
Thu Sep 17 22:12:00 GMT 1998


> From: "Melissa O'Neill" <oneill@cs.sfu.ca>
> Date: Wed, 16 Sep 1998 23:09:02 -0700

> 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.)

Well, if the object file format supports an initialization and
finalization, then crtstuff kicks in and it is handled that way.  If
the object format doesn't support it, then it just doesn't support it,
and the user must arrange to do it.  In a world without a standard way
of running code, it is up to the user.  Sorry.  However, if the user
follows through on this requirement, it does (should) work.

So, what you need to do, is, upon dynamic load, just run all the ctors
and register the frames, and on unload, run all the dtors, no?  Why
can't this work?

As to multiple symbols, you want a dynloader that when it loads in the
object, runs through the symbol table for the object and calls the
initialization routines, and registers the frames for the object, and
upon unload, calls the descructors.  Not pretty, but it works.

If you want it to be easier, then we can add another couple library
elements on such systems that given access to the sombol table will do
the initializations, and register the frames for you, and another hook
for unload time, that will destroy/unregister things for you.  If
there are hooks into the dyn loading/unloading, then maybe we can rid
it all up to automatically work.



More information about the Gcc mailing list