Re: A completely different approach to EH runtime

[Mike Stump <mrs at windriver dot com>]

> From: Joe Buck <jbuck@synopsys.COM>
> To: rth@redhat.com (Richard Henderson)
> Date: Fri, 23 Feb 2001 15:09:12 -0800 (PST)

> Richard Henderson writes:
> > Yep, the same thing we do for targets without linkonce.
> > Namely, strcmp vs pointer equality.

> I strongly agree with Richard's suggestion.  We must treat linkonce as
> only an optimization, never relying on it for correct functionality --
> especially because the concept doesn't exist on some target platforms,
> but even where it does exist, there are difficulties, both with dynamic
> loading and with other types of partial linking.

This is a very unfortunate thing to think/say.  It constrains the
compiler from producing fast/efficient code.  Better to _fix_ the
other types of uses so that they work, and provide all the necessary
tools on platforms that are limited.  Then, those plaforms are more
featureful and the speed and efficiency remain.  If we resolve to not
try and fix the problem, then we just wind up with a slower system.

Be sure to fix the instantiation of static data for extern inlines as
well.  But, out of curiosity, how did you envision fixing those?

extern inline void *foo() {
  static int i;
  return &i;
}

Here the value returned must be the same across all translation units.
strcmp doesn't quite work by itself.  Now, if we have a runtime symbol
table, and consult and use it for symbol table look ups, gosh, wait,
didn't another piece of software already provide that functionality,
why yes, and then we just duplicate all that functionality.  Why is
this advantageous than just getting them to fix whatever bugs we find
in their code?