From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23664 invoked by alias); 10 Dec 2001 19:39:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23643 invoked from network); 10 Dec 2001 19:39:29 -0000 Received: from unknown (HELO gandalf.codesourcery.com) (66.60.148.227) by sources.redhat.com with SMTP; 10 Dec 2001 19:39:29 -0000 Received: from gandalf.codesourcery.com (IDENT:mitchell@localhost [127.0.0.1]) by gandalf.codesourcery.com (8.11.6/8.11.6) with ESMTP id fBAJWP828713; Mon, 10 Dec 2001 11:32:25 -0800 Date: Mon, 10 Dec 2001 11:39:00 -0000 From: Mark Mitchell To: Joe Buck cc: Lubos Lunak , "kde-core-devel@mail.kde.org" , Franz Sirl , "gcc@gcc.gnu.org" Subject: Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Message-ID: <47830000.1008012745@gandalf.codesourcery.com> In-Reply-To: <200112101914.LAA17216@atrus.synopsys.com> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2001-12/txt/msg00527.txt.bz2 --On Monday, December 10, 2001 11:14:30 AM -0800 Joe Buck 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