Re: Exception handling, dynamic linking and weak symbol tricks

[mrs at wrs dot com (Mike Stump)]

> From: "Melissa O'Neill" <oneill@cs.sfu.ca>
> Date: Wed, 16 Sep 1998 16:20:19 -0700
> To: egcs@cygnus.com
> cc: mrs@wrs.com (Mike Stump), oneill@cs.sfu.ca

> I wrote:
> > the new
> > > ``__throw'' method for exception handling does not appear to be
> > > compatible with dynamic linking at all (at least in its current
> > > incarnation), since seems to assume that frame information will be
> > > statically determined.

> ... Mike Stump replied:
> > Not compatible?  [...]  I think the underlying scheme was designed to
> > support dynamic loading and unloading of code.

> I think the underlying scheme can support dynamic loading and
> unloading of code, but parts of the current realization (especially
> on systems without gnu ld, where collect2 gets used to handle frame
> table initialization) seem to assume that there is a single
> exceptions table that is statically determined.

> The internals of exception handling and the mechanisms of dynamic linking
> are not my fields of expertise. But, after happening to stare at
> gthr-posix.h and frame.c for a while, I had some nagging worries, so it
> sensible to raise the issue here. If my worries are unfounded, so much
> the better.

Here we go again.  Please just state your worries, and have them
confirmed or have it explained to you why it will work.  The stating
of things like, the compiler I think might have a bug in it, is just
plain useless, and that is how I read you statements.

Try using routine names, try explaining the scenario.  Try explaining
_why_ you think it won't work.

Try something like `The routine __deregister_frame can't possible
deregister a frame because ...' or `The __register_frame_table doesn't
arrange for new FDEs to be found because ...'.

Lastly, there is no need to worry.  :-) Just use it, it should just
work.  If it fails to do that, then it should just be fixed.