* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) [not found] <Pine.LNX.4.42.0112041339390.30216-110000@bochum.stuttgart.redhat.com> @ 2001-12-04 13:21 ` Waldo Bastian 2001-12-04 13:29 ` shaheed ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Waldo Bastian @ 2001-12-04 13:21 UTC (permalink / raw) To: kde-core-devel; +Cc: gcc On Tuesday 04 December 2001 04:40 am, Bernhard Rosenkraenzer wrote: > FYI > > ---------- Forwarded message ---------- > Date: Mon, 3 Dec 2001 17:17:55 +0100 > From: Jakub Jelinek <jakub@redhat.com> > To: <some-internal-list@redhat.com> > Subject: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC > 3.0.3: Bugs to Fix]) > > Hi! > > If you want dynamic cast (and that's just one thing) to work with dlopen in > gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan not > understanding what if and only if means). That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is asking for trouble. There is no way that we can guarantee that one part doesn't by chance use the same name for some class/symbols as another part, since parts may get developed independently of each other. We are already running into trouble with the flash plugin colliding with OpenGL (both define "DisplayList") and things like this aren't helping the situation. The alternative, banning RTTI from KDE, isn't very attractive either. Cheers, Waldo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 13:21 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Waldo Bastian @ 2001-12-04 13:29 ` shaheed 2001-12-04 14:51 ` Joe Buck 2001-12-05 1:23 ` Nathan Sidwell 2 siblings, 0 replies; 19+ messages in thread From: shaheed @ 2001-12-04 13:29 UTC (permalink / raw) To: kde-core-devel; +Cc: gcc Hi > > If you want dynamic cast (and that's just one thing) to work with dlope > > in gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan no > > understanding what if and only if means) > That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL i > asking for trouble. There is no way that we can guarantee that one par > doesn't by chance use the same name for some class/symbols as another part > since parts may get developed independently of each other > We are already running into trouble with the flash plugin colliding wit > OpenGL (both define "DisplayList") and things like this aren't helping th > situation > The alternative, banning RTTI from KDE, isn't very attractive either Note that there is at least one use of RTTI in the MS Word import filter for KWord. It *could* be eliminated in favour of an alternative hack if required, but RTTI is needed at present at least Thanks, Shahee ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 13:21 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Waldo Bastian 2001-12-04 13:29 ` shaheed @ 2001-12-04 14:51 ` Joe Buck 2001-12-04 16:37 ` Dirk Mueller 2001-12-09 23:58 ` Waldo Bastian 2001-12-05 1:23 ` Nathan Sidwell 2 siblings, 2 replies; 19+ messages in thread From: Joe Buck @ 2001-12-04 14:51 UTC (permalink / raw) To: Waldo Bastian; +Cc: kde-core-devel, gcc Jakub Jelinek <jakub@redhat.com> wrote: > > If you want dynamic cast (and that's just one thing) to work with dlopen in > > gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan not > > understanding what if and only if means). Waldo Bastian wrote: > That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is > asking for trouble. There is no way that we can guarantee that one part > doesn't by chance use the same name for some class/symbols as another part, > since parts may get developed independently of each other. > > We are already running into trouble with the flash plugin colliding with > OpenGL (both define "DisplayList") and things like this aren't helping the > situation. But that causes an interesting problem. You say that you don't want to use RTLD_GLOBAL because someone might duplicate a class name (say, "DisplayList"). Of course, this violates the one-definition rule, but let's ignore that for a moment. But if you want to allow multiple definitions of the same class, then I don't see what dynamic_cast<DisplayList*>(foo) is supposed to mean. One possible definition is for the strings of all base classes of foo to be checked for a match. But what if that turns out to be a different DisplayList than the one the current compilation unit knows about? Also there is a speed penalty to be paid if we must do this string-compare, possibly a substantial one. Certainly there are hashing techniques that could be used to make the lookup faster, but we're between a rock and a hard place: we signed up to implement a standard ABI that multiple compiler vendors agreed on, and it puts constraints on the RTTI implementation. Even if the g++ team agrees to solve it for you, it would just mean that KDE can't be built by the other compilers, like Intel's, SGI's, or HP's. > The alternative, banning RTTI from KDE, isn't very attractive either. What if you only use RTLD_GLOBAL for those libraries that define base classes that you'll want to do RTTI with? Or use it everywhere except with libraries that you know are problematic and sloppy with name spaces, like the flash plugin and OpenGL. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 14:51 ` Joe Buck @ 2001-12-04 16:37 ` Dirk Mueller 2001-12-05 12:16 ` Mark Mitchell 2001-12-09 23:58 ` Waldo Bastian 1 sibling, 1 reply; 19+ messages in thread From: Dirk Mueller @ 2001-12-04 16:37 UTC (permalink / raw) To: Joe Buck; +Cc: Waldo Bastian, kde-core-devel, gcc On Die, 04 Dez 2001, Joe Buck wrote: > But that causes an interesting problem. You say that you don't want to > use RTLD_GLOBAL because someone might duplicate a class name (say, > "DisplayList"). Of course, this violates the one-definition rule, but > let's ignore that for a moment. Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in order to make RTTI work, as the original posting pointed out ? I think lazy symbol resolving is the least thing an ABI should be capable of when living in the 21th century.. Dirk ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 16:37 ` Dirk Mueller @ 2001-12-05 12:16 ` Mark Mitchell 0 siblings, 0 replies; 19+ messages in thread From: Mark Mitchell @ 2001-12-05 12:16 UTC (permalink / raw) To: Dirk Mueller, Joe Buck; +Cc: Waldo Bastian, kde-core-devel, gcc --On Wednesday, December 05, 2001 01:35:51 AM +0100 Dirk Mueller <dmuell@gmx.net> wrote: > On Die, 04 Dez 2001, Joe Buck wrote: > >> But that causes an interesting problem. You say that you don't want to >> use RTLD_GLOBAL because someone might duplicate a class name (say, >> "DisplayList"). Of course, this violates the one-definition rule, but >> let's ignore that for a moment. > > Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in > order to make RTTI work, as the original posting pointed out ? I don't think you should (I would think RTLD_LAZY would be OK), but I am not the world's biggest dynamic linking expert... -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 14:51 ` Joe Buck 2001-12-04 16:37 ` Dirk Mueller @ 2001-12-09 23:58 ` Waldo Bastian 2001-12-10 0:52 ` Simon Hausmann ` (3 more replies) 1 sibling, 4 replies; 19+ messages in thread From: Waldo Bastian @ 2001-12-09 23:58 UTC (permalink / raw) To: Joe Buck, Franz Sirl; +Cc: kde-core-devel, gcc On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote: > > The alternative, banning RTTI from KDE, isn't very attractive either. > > What if you only use RTLD_GLOBAL for those libraries that define base > classes that you'll want to do RTTI with? Or use it everywhere except > with libraries that you know are problematic and sloppy with name spaces, > like the flash plugin and OpenGL. The problem that we had was with things like templates. If two plugins use the same template, they will get the same symbol-names. When the symbols are loaded in the global namespace, it can happen that plugin A resolves against the symbols of plugin B. When you now unload plugin B you will get a crash the next time you access plugin A. (Unloading plugins is a risky business anyway, because with 2.9x the process will crash on exit when there were static objects declared within function-scope in the plugin.) To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at PR3993 breakage there seems to happen because the module that does the dlopen'ing doesn't strongly define class B (how do you call that, "class B isn't being emitted"?) That situation could be prevented most of the time I think. (I believe such classes also have a negative impact on prelinking) Wouldn't then the only remaining problem be classes that are defined in both plugin A and plugin B (e.g. template) but aren't defined in the module that loads them? RTTI-wise such classes would be considered distinct then if I understand correctly? Franz: You described PR3993 as "another KDE2 blocking bug", where does this behaviour break stuff in KDE? Cheers, Waldo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-09 23:58 ` Waldo Bastian @ 2001-12-10 0:52 ` Simon Hausmann 2001-12-10 2:45 ` Lubos Lunak 2001-12-10 1:33 ` Richard Henderson ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: Simon Hausmann @ 2001-12-10 0:52 UTC (permalink / raw) To: kde-core-devel; +Cc: Joe Buck, Franz Sirl, gcc On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote: > To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at > PR3993 breakage there seems to happen because the module that does the > dlopen'ing doesn't strongly define class B (how do you call that, "class B > isn't being emitted"?) That situation could be prevented most of the time I > think. (I believe such classes also have a negative impact on prelinking) I think both 'modules', the dlopen'ing app as well as the shared library do contain the actual RTTI info. However (see also comments on PR4993) neither the app has been linked with --export-dynamic nor is the shared library dlopen'ed with RTDL_GLOBAL, hence the weak rtti symbols in the shared library aren't resolved to the existing onces in the app -> with duplicated RTTI info for the same class the pointer comparison fails. > Franz: You described PR3993 as "another KDE2 blocking bug", where does this > behaviour break stuff in KDE? The regular expression editor is one example (it is loaded dynamically in khtml/kate/klipper, exactly like in 3993) , some of the texteditor interfaces in kdelibs/interfaces another one. If we don't want to use RTLD_GLOBAL I see too solutions from our side: 1) Use intermediate shared libraries. Like the regular expression editor component gets another shared library to which all apps using the component would have to link against. This doesn't scale very well for a big amount of components. 2) Don't use C++ RTTI to determine whether the given object inherits from the pure base class but use Qt RTTI instead (qt_cast) . Syntactically not as beautiful (we could hide it behind a d-cast like template though) it does quite the same job as when C++ rtti falls back on the string comparison approach. (which while being slower should still be fine for KDE as we usually don't do that casting in inner loops or other time critical places - I think functionality is here more important) Simon ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-10 0:52 ` Simon Hausmann @ 2001-12-10 2:45 ` Lubos Lunak 2001-12-10 9:55 ` Mark Mitchell 0 siblings, 1 reply; 19+ messages in thread From: Lubos Lunak @ 2001-12-10 2:45 UTC (permalink / raw) To: kde-core-devel; +Cc: Joe Buck, Franz Sirl, gcc On Mon 10. December 2001 09:39, Simon Hausmann wrote: [snip] > > The regular expression editor is one example (it is loaded > dynamically in khtml/kate/klipper, exactly like in 3993) , some of > the texteditor interfaces in kdelibs/interfaces another one. If we > don't want to use RTLD_GLOBAL I see too solutions from our side: > > 1) Use intermediate shared libraries. Like the regular expression > editor component gets another shared library to which all apps > using the component would have to link against. This doesn't > scale very well for a big amount of components. > > 2) Don't use C++ RTTI to determine whether the given object inherits > from the pure base class but use Qt RTTI instead (qt_cast) . > Syntactically not as beautiful (we could hide it behind a d-cast > like template though) it does quite the same job as when C++ rtti > falls back on the string comparison approach. (which while being > slower should still be fine for KDE as we usually don't do that > casting in inner loops or other time critical places - I think > functionality is here more important) > Maybe I'm missing something obvious, but how about this one? 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. It seems to be very similar to 2), with some advantages, like working also for classes not inheriting from QObject without problems. Also whether dynamic_cast etc. uses just pointer comparing or string comparing shouldn't(?) affect the ABI, so I don't see any serious problem with it. -- Lubos Lunak llunak@suse.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-10 2:45 ` Lubos Lunak @ 2001-12-10 9:55 ` Mark Mitchell 2001-12-10 11:16 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Joe Buck 2001-12-11 13:00 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Alexandre Oliva 0 siblings, 2 replies; 19+ messages in thread From: Mark Mitchell @ 2001-12-10 9:55 UTC (permalink / raw) To: Lubos Lunak, kde-core-devel; +Cc: Joe Buck, Franz Sirl, gcc > 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. 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 general, I will argue against any such change. Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong. The right model is that this is like using an uninitialized variable. It might work somtimes, but it is a completely horrible thing to do, totally unportable, and will succeed or fail based on minor changes elsewhere in the code. It would be a disservice for us to add features that try to accomodate this; they cannot be made to work reliably and so all they would do is create a temptation for people to write code that will not work. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 2001-12-10 9:55 ` Mark Mitchell @ 2001-12-10 11:16 ` Joe Buck 2001-12-10 11:39 ` Mark Mitchell 2001-12-11 13:00 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Alexandre Oliva 1 sibling, 1 reply; 19+ messages in thread From: Joe Buck @ 2001-12-10 11:16 UTC (permalink / raw) To: Mark Mitchell; +Cc: Lubos Lunak, kde-core-devel, Joe Buck, Franz Sirl, gcc > > > 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. It might be possible to have a design that would only require special treatment for code containing RTTI operations where types cross a dynamic library boundary, but to still use the same standard library. Just the same, it's not reasonable for the KDE folks to expect the gcc folks to design such a feature for them. It's not C++. KDE isn't going to work with any of the other x86-on-Linux compilers either (SGI, Intel) if it requires such a feature. > Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong. This goes too far. In many cases it is very useful; we certainly used the technique heavily in the Ptolemy project, and made it work on many Unix flavors plus Windows (however, the use was more restricted: it allowed the dynamic loading of derived classes for which the base classes were already in the core application with globally available symbols, and builtin RTTI operations like dynamic_cast were not used). 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 2001-12-10 11:16 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Joe Buck @ 2001-12-10 11:39 ` Mark Mitchell 2001-12-10 11:47 ` Joe Buck 0 siblings, 1 reply; 19+ messages in thread From: Mark Mitchell @ 2001-12-10 11:39 UTC (permalink / raw) To: Joe Buck; +Cc: Lubos Lunak, kde-core-devel, Franz Sirl, gcc --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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 2001-12-10 11:39 ` Mark Mitchell @ 2001-12-10 11:47 ` Joe Buck 0 siblings, 0 replies; 19+ messages in thread From: Joe Buck @ 2001-12-10 11:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Lubos Lunak, kde-core-devel, Franz Sirl, gcc > 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. No kidding. Elaborate reference counting mechanisms to make sure we don't delete code objects where we still have data objects whose vtables don't point there, the quirks of five completely distinct dynamic linking systems on different OSes, etc. On the other hand, I used g++ in 1990. That was fire, man. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-10 9:55 ` Mark Mitchell 2001-12-10 11:16 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Joe Buck @ 2001-12-11 13:00 ` Alexandre Oliva 2001-12-11 9:28 ` Mark Mitchell 1 sibling, 1 reply; 19+ messages in thread From: Alexandre Oliva @ 2001-12-11 13:00 UTC (permalink / raw) To: Mark Mitchell; +Cc: Lubos Lunak, kde-core-devel, Joe Buck, Franz Sirl, gcc On Dec 10, 2001, Mark Mitchell <mark@codesourcery.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. > 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. Err... Wouldn't it be enough to link with a modified version of the object file that implements rtti comparison? Or are such comparisons ever inlined in the generated code? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-11 13:00 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Alexandre Oliva @ 2001-12-11 9:28 ` Mark Mitchell 0 siblings, 0 replies; 19+ messages in thread From: Mark Mitchell @ 2001-12-11 9:28 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Lubos Lunak, kde-core-devel, Joe Buck, Franz Sirl, gcc --On Tuesday, December 11, 2001 03:09:53 PM -0200 Alexandre Oliva <aoliva@redhat.com> wrote: > On Dec 10, 2001, Mark Mitchell <mark@codesourcery.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. > >> 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. > > Err... Wouldn't it be enough to link with a modified version of the > object file that implements rtti comparison? Or are such comparisons > ever inlined in the generated code? They are typically inlined. From <typeinfo>: class type_info { ... bool operator==(const type_info& __arg) const { return __name == __arg.__name; } }; There you have it. We certainly want to inline these; they are almost free. The point I tried to make yesterday, but apparently somewhat unsuccessfully, is that RTTI is only the tip of the iceberg. You might be able to fix this -- but you can't fix all the problems, and it's not easy to specify what subset of the language you can support. It's a mistake to try. It's much better to tell your customers how to use your product successfully than to encourage them to use a technique likely to fail. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-09 23:58 ` Waldo Bastian 2001-12-10 0:52 ` Simon Hausmann @ 2001-12-10 1:33 ` Richard Henderson 2001-12-10 2:41 ` Andreas Schwab 2001-12-10 2:07 ` Nathan Sidwell 2001-12-10 3:01 ` Jakub Jelinek 3 siblings, 1 reply; 19+ messages in thread From: Richard Henderson @ 2001-12-10 1:33 UTC (permalink / raw) To: Waldo Bastian; +Cc: Joe Buck, Franz Sirl, kde-core-devel, gcc On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote: > ... it can happen that plugin A resolves against > the symbols of plugin B. When you now unload plugin B you will get a crash > the next time you access plugin A. FWIW, this should be fixed in glibc 2.2.4. If A references B, then an unload of B will not actually occur until A unloads. r~ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-10 1:33 ` Richard Henderson @ 2001-12-10 2:41 ` Andreas Schwab 0 siblings, 0 replies; 19+ messages in thread From: Andreas Schwab @ 2001-12-10 2:41 UTC (permalink / raw) To: Richard Henderson Cc: Waldo Bastian, Joe Buck, Franz Sirl, kde-core-devel, gcc Richard Henderson <rth@redhat.com> writes: |> On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote: |> > ... it can happen that plugin A resolves against |> > the symbols of plugin B. When you now unload plugin B you will get a crash |> > the next time you access plugin A. |> |> FWIW, this should be fixed in glibc 2.2.4. If A references B, |> then an unload of B will not actually occur until A unloads. IIRC there were some bugs left in this area even in 2.2.4, but they should be fixed in current CVS. Andreas. -- Andreas Schwab "And now for something Andreas.Schwab@suse.de completely different." SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-09 23:58 ` Waldo Bastian 2001-12-10 0:52 ` Simon Hausmann 2001-12-10 1:33 ` Richard Henderson @ 2001-12-10 2:07 ` Nathan Sidwell 2001-12-10 3:01 ` Jakub Jelinek 3 siblings, 0 replies; 19+ messages in thread From: Nathan Sidwell @ 2001-12-10 2:07 UTC (permalink / raw) To: Waldo Bastian; +Cc: Joe Buck, Franz Sirl, kde-core-devel, gcc Waldo Bastian wrote: > > On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote: > > > The alternative, banning RTTI from KDE, isn't very attractive either. > > > > What if you only use RTLD_GLOBAL for those libraries that define base > > classes that you'll want to do RTTI with? Or use it everywhere except > > with libraries that you know are problematic and sloppy with name spaces, > > like the flash plugin and OpenGL. > > The problem that we had was with things like templates. If two plugins use the > same template, they will get the same symbol-names. When the symbols are > loaded in the global namespace, it can happen that plugin A resolves against > the symbols of plugin B. When you now unload plugin B you will get a crash > the next time you access plugin A. Isn't this a bug in the DL machinery. Why can't it track the dependency DAG? (or is unloading specifically undefined in such a case?) > To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at > PR3993 breakage there seems to happen because the module that does the > dlopen'ing doesn't strongly define class B (how do you call that, "class B > isn't being emitted"?) That situation could be prevented most of the time I > think. (I believe such classes also have a negative impact on prelinking) Not saying RTLD_GLOBAL (and linking the main executable with -E), effectively places each dlopen'd library in its own namespace. RTTI across library boundaries would not work. nathan -- Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC 'But that's a lie.' - 'Yes it is. What's your point?' nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-09 23:58 ` Waldo Bastian ` (2 preceding siblings ...) 2001-12-10 2:07 ` Nathan Sidwell @ 2001-12-10 3:01 ` Jakub Jelinek 3 siblings, 0 replies; 19+ messages in thread From: Jakub Jelinek @ 2001-12-10 3:01 UTC (permalink / raw) To: Waldo Bastian; +Cc: Joe Buck, Franz Sirl, kde-core-devel, gcc On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote: > (Unloading plugins is a risky business anyway, because with 2.9x the process > will crash on exit when there were static objects declared within > function-scope in the plugin.) This should work, provided you have recent enough glibc (2.2.4) and use recent enough compiler for both glibc building and to build all relevant shared libs (CVS 2.95.x with __dso_handle should work, 2.96-RH too, gcc3+ likewise). If you see any problems, please file a bug report against glibc. Jakub ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) 2001-12-04 13:21 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Waldo Bastian 2001-12-04 13:29 ` shaheed 2001-12-04 14:51 ` Joe Buck @ 2001-12-05 1:23 ` Nathan Sidwell 2 siblings, 0 replies; 19+ messages in thread From: Nathan Sidwell @ 2001-12-05 1:23 UTC (permalink / raw) To: Waldo Bastian, Dirk Mueller; +Cc: kde-core-devel, gcc Waldo Bastian wrote: > That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is > asking for trouble. There is no way that we can guarantee that one part > doesn't by chance use the same name for some class/symbols as another part, > since parts may get developed independently of each other. > > We are already running into trouble with the flash plugin colliding with > OpenGL (both define "DisplayList") and things like this aren't helping the > situation. Other than reiterating what Joe Buck said, what you describe sounds like a job for namespaces. Ok, so you'd have to retrofit them - but you've got to do something retroactively anyway. If you cannot do that then you might be able to do some linker symbol remapping. For instance, a) all the classes you wish to be dcastable/throwable across shared library boundaries should be placed in the 'ReallyGlobal' namespace (for want of a better name :-) b) when building the shared library prefix any symbol which is not an export or import to/from the library and not in the ReallyGlobal namespace with 'PrivateToLibFoo' That sounds tricky to me, but as Joe pointed out - you've broken the one definition rule and 'magically' want the compilation system to know which multiply defined objects are the same and which are different. Dirk Mueller wrote: > Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in order > to make RTTI work, as the original posting pointed out ? You should be able to do it lazily too. But, RTLD_GLOBAL doesn't work on (at least) gnu.linux i86 (see gcc bug 4993). I've not had time to investigate further, but aim to do so shortly. nathan -- Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC 'But that's a lie.' - 'Yes it is. What's your point?' nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2001-12-11 21:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.LNX.4.42.0112041339390.30216-110000@bochum.stuttgart.redhat.com> 2001-12-04 13:21 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Waldo Bastian 2001-12-04 13:29 ` shaheed 2001-12-04 14:51 ` Joe Buck 2001-12-04 16:37 ` Dirk Mueller 2001-12-05 12:16 ` Mark Mitchell 2001-12-09 23:58 ` Waldo Bastian 2001-12-10 0:52 ` Simon Hausmann 2001-12-10 2:45 ` Lubos Lunak 2001-12-10 9:55 ` Mark Mitchell 2001-12-10 11:16 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC Joe Buck 2001-12-10 11:39 ` Mark Mitchell 2001-12-10 11:47 ` Joe Buck 2001-12-11 13:00 ` KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Alexandre Oliva 2001-12-11 9:28 ` Mark Mitchell 2001-12-10 1:33 ` Richard Henderson 2001-12-10 2:41 ` Andreas Schwab 2001-12-10 2:07 ` Nathan Sidwell 2001-12-10 3:01 ` Jakub Jelinek 2001-12-05 1:23 ` Nathan Sidwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).