Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC

[Mark Mitchell <mark at codesourcery dot com>]

--On Monday, December 10, 2001 11:14:30 AM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

>>
>> >    3) Persuade gcc folks to add compiler switch that makes gcc use
>> >    string comparing when doing rtti, and simply compile whole KDE with
>> > this switch turned on.
>
> Mark writes:
>> All code in the application -- including the C++ run-time library --
>> needs to be compiled the same way, so you would have to rebuild
>> everything to do this.
>
> In this case, that isn't clear to me.  All code needs to be compiled the
> same way if the flag in question produces an incompatible ABI, but I'm
> not sure it would necessarily be true in this case.

This is exactly the kind of thing we shouldn't tell people. :-)

It is true that if you use strcmp with class data structures that
expect address comparison, you are safe.  The other direction is not
safe.  So, if there is ever a use of RTTI or exception-handling in
the code that was compiled without the special switch, but applying
to classes from the code compiled with the special switch, you have
problems.

>> Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong.
>
> This goes too far.

Well, perhaps.  See below.

> What's broken in the KDE case is that two contradictory things are being
> requested: RTTI assuming a global type system, and dynamic loading
> assuming private type systems.

That's the *specific* thing that's going wrong this time.  There are
lots of other things that might go wrong, and even enumerating them
is difficult.  Nathan already mentioned the fact that the same
template instantiation may have multiple addresses.  That applies
to static data members, not just functions; this is a potentially
catastrophic problem.

(The compiler is also allowed to depend on function address comparisions 
when optimizing, even if the code does not do so explicitly:

  int id(int i) { return i; }

  void f(int (*fp)(int), int i) {
    return fp(i);
  }

could be transformed into:

  void f(int (*fp)(int), int i) {
    if (fp == &id) return i;
    else return fp(i);
  }

We don't currently ever do this, but we could.)

There are other objects with vague linkage besides RTTI data, such as
static data in inline functions with external linkage.

Remember that your code need not have these constructs; all that is
necessary is that you #include something that does, including something
from the standard library.

Yes, if you really, really know what you are doing and you are willing
to write code that is unportable, or that does not make use of many
language features, and you know the ABI, you may be able to get away
with this.

You are, however, playing with fire.

I certainly do not think that G++ should be obliged to make any
guarantees about this situation.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com