Re: Exceptions workaround for older systems that don't USE_COLLECT2

[Jeffrey A Law <law at cygnus dot com>]

  In message <199809090618.XAA29438@aldrington.ppp.cs.sfu.ca>you write:
  > Yes, the x86 port should need to use collect as well. Ditto for HPPA
  > and SPARC NEXTSTEP versions, if they are supported by EGCS. It's the
  > same basic linker and object format, so their behaviour should be
  > more-or-less identical across processor architectures.
Done for the x86.  gcc doesn't support NeXT on the PA or SPARC.

I'd forgotten about NeXT's "unique" linker.  NeXT (years ago) actually
drove HP's (slow) movement away from the SOM object format and into a
ELF with a less efficient runtime model which required less linker
support.

I had the, err, distinct pleasure of reviewing the various ABI changes
put forth by the different players in that little game, then having
to implement both runtime models in ELF.  I do not have fond memories
of that work.

  > Interesting. I had thought that linking code that used exceptions
  > together with code that doesn't use them had unspecified results anyway
  > (at least in general, if you're allowed to use pointers to functions,
  > have call-backs, etc.), or am I mistaken?
You should be able to still throw code within the code which was compiled
with exception handling enabled.  Throwing through a routine that does 
not have exception handling enabled has undefined behavior.

  > Someone could probably argue that invoking g++ to link object files and
  > specifying `-fno-exceptions' could be seen as an assertion that none of
  > the object files or libraries use exceptions, but the argument is academic
  > anyway since no one is poised to implement such a feature...
Nope.  That is not what -fno-exception means.  -fno-exceptions means
to not emit code to allow throws through the current compilation unit.

jeff