Hello all, I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso Is it using name or address comparison? We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… (Mac OS X 10.6/10.7, clang 3.0) Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/fa98a57f/attachment.html>
LLVM does not use RTTI--it has its own mechanisms; see llvm/include/llvm/Support/Casting.h, and by default it is turning off for an LLVM build. Garrison On Sep 30, 2011, at 12:15, Somorjai, Akos wrote:> Hello all, > > I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso > > Is it using name or address comparison? > > We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. > In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… > > (Mac OS X 10.6/10.7, clang 3.0) > > Thanks, > Ákos Somorjai > Developer Support Manager > > GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/8aeb354c/attachment.html>
On Sep 30, 2011, at 9:15 AM, Somorjai, Akos wrote:> I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dsoThis is really a Clang question and so belongs on cfe-dev.> Is it using name or address comparison?Clang strives for interoperability with GCC, which means we use address comparison on targets where GCC does. Therefore yes, we have the same issues with symbol visibility and vague linkage.> We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. > In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm…The best solution, bar none, is to avoid the need for vague linkage on your RTTI objects. If they correspond to polymorphic class types, which presumably they do if your problems are with dynamic_cast, then you need to use key functions more effectively. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/04d930f7/attachment.html>
On Sep 30, 2011, at 10:16 AM, Garrison Venn wrote:> On Sep 30, 2011, at 12:15, Somorjai, Akos wrote: > >> Hello all, >> >> I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso >> >> Is it using name or address comparison? >> >> We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. >> In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… >> >> (Mac OS X 10.6/10.7, clang 3.0) > > LLVM does not use RTTI--it has its own mechanisms; see llvm/include/llvm/Support/Casting.h, and by default it is turning off for an LLVM build.I don't think that's what the OP meant. I think he's talking about using RTTI in his code - how LLVM generated code (and/or LLVM runtime libraries) handle RTTI. I expect the answer is "The same as gcc, since code compiled with LLVM needs to interoperate with code compiled with gcc. [ I too would like a better way of handling RTTI and dynamic libraries ] -- Marshall Marshall Clow Idio Software <mailto:mclow.lists at gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/ed0b49fd/attachment.html>
Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where we don't really have any control? Just being curious, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Fri, 30 Sep 2011 10:22:02 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: Re: [LLVMdev] RTTI handling On Sep 30, 2011, at 9:15 AM, Somorjai, Akos wrote: I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso This is really a Clang question and so belongs on cfe-dev. Is it using name or address comparison? Clang strives for interoperability with GCC, which means we use address comparison on targets where GCC does. Therefore yes, we have the same issues with symbol visibility and vague linkage. We have an architecture with several frameworks and plug-ins; some of the latter are being loaded and unloaded runtime. In the past that issue caused crashes in our app, so at the moment we are overriding __dynamic_cast to detect this problem, but that's kind of messy. I'm hoping for a better solution with llvm… The best solution, bar none, is to avoid the need for vague linkage on your RTTI objects. If they correspond to polymorphic class types, which presumably they do if your problems are with dynamic_cast, then you need to use key functions more effectively. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/8355c025/attachment.html>