public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/23628] Typeinfo comparison code easily breaks shared libs Date: Thu, 01 Sep 2005 10:42:00 -0000 [thread overview] Message-ID: <20050901104243.675.qmail@sourceware.org> (raw) In-Reply-To: <20050829194742.23628.mmarcus@emarcus.org> ------- Additional Comments From s_gccbugzilla at nedprod dot com 2005-09-01 10:42 ------- Vladimir Prus Wrote: > It's is mess, but I hope that we don't just agree on *that*. The situation > is that the whole -fvisibility thing does not work reliably for C++ > dynamic libraries which is rather bad. I wouldn't go /that/ far - if you know what you're doing, it's completely reliable. The problem is that it involves a lot of knowledge of ELF internals which most people using GCC don't have and IMHO, shouldn't need to have. The problem I see here is that Andrew knows the internals of GCC extremely well, and so to him IMHO he can't see why users are having such a problem. > You might be formally right, but what about practical consequences? Unless > *all* libraries I use have push/pops in *every single header*, using > -fvisibility for my own library can result in crash. So for a large > application you'd need to get authors of all used libraries to "fix" them! > Note that even libstdc++ does not have this at the moment. This makes > -fvisibility just useless. One of our overriding goals when making this patch was to AVOID patching any existing library headers! See PR 9283 and PR 15000. The way I see it is that GCC's current behaviour interferes with the ODR. If you define a type in one compilation unit and then again in another, and you compare the two, currently it works if those compilation units are in the same shared object but it fails if they are in different shared objects. This to me is confusing at best, and causes hard-to-find bugs at worst. It also isn't compatible with MSVC's behaviour which was also one of the original goals of the patch - to allow existing MSVC DLL macro support to be reused in GCC. Now I raised this originally back in the day, but I was told that the performance penalty of memcmp()-ing symbols was too much - even though MSVC does just this and I haven't seen many complaints about its typeinfo performance. However, I am very certain that so long as it remains this way, you're just going to get more and more people complaining in here. So how about this - how about we get GCC to emit a special linkonce symbol called say __gcc_linkonce_nondefaultvisibility if a compilation unit uses non- default visibility? And if that symbol is present, the GCC runtime uses memcmp() instead of address comparison during typeinfo work - if I remember, there's about two or three places where code would need altering. This solves the problem, and keeps everyone happy. If people agree, I could contribute a little to this patch. Cheers, Niall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628
next prev parent reply other threads:[~2005-09-01 10:42 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-08-29 19:55 [Bug c++/23628] New: " mmarcus at emarcus dot org 2005-08-29 19:58 ` [Bug c++/23628] " pinskia at gcc dot gnu dot org 2005-08-29 19:59 ` pinskia at gcc dot gnu dot org 2005-08-29 20:23 ` mmarcus at emarcus dot org 2005-08-29 20:27 ` mmarcus at emarcus dot org 2005-08-29 20:30 ` pinskia at gcc dot gnu dot org 2005-08-29 20:31 ` pinskia at gcc dot gnu dot org 2005-08-29 20:34 ` pinskia at gcc dot gnu dot org 2005-08-29 20:40 ` pinskia at gcc dot gnu dot org 2005-08-29 20:49 ` mmarcus at emarcus dot org 2005-08-29 20:56 ` pinskia at gcc dot gnu dot org 2005-08-29 20:57 ` pinskia at gcc dot gnu dot org 2005-08-29 21:01 ` mmarcus at emarcus dot org 2005-08-29 21:05 ` mmarcus at emarcus dot org 2005-08-29 21:11 ` pinskia at gcc dot gnu dot org 2005-08-29 21:32 ` mmarcus at emarcus dot org 2005-08-29 21:32 ` Andrew Pinski 2005-08-29 21:57 ` pinskia at physics dot uc dot edu 2005-08-29 22:14 ` mmarcus at emarcus dot org 2005-08-30 13:17 ` ghost at cs dot msu dot su 2005-08-30 13:44 ` gdr at integrable-solutions dot net 2005-08-31 7:19 ` ghost at cs dot msu dot su 2005-08-31 14:21 ` pinskia at gcc dot gnu dot org 2005-08-31 14:39 ` ghost at cs dot msu dot su 2005-08-31 14:56 ` gdr at integrable-solutions dot net 2005-09-01 8:35 ` mmarcus at emarcus dot org 2005-09-01 10:42 ` s_gccbugzilla at nedprod dot com [this message] [not found] <bug-23628-10681@http.gcc.gnu.org/bugzilla/> 2006-01-21 21:02 ` rjohnson at dogstar-interactive dot com 2006-01-21 21:45 ` gdr at cs dot tamu dot edu 2006-09-18 21:02 ` geoffk at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050901104243.675.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).