[cxx-abi-dev] Deleted virtual functions

Sean Perry perry at ca.ibm.com
Tue Jun 2 20:49:13 UTC 2009


Hey, that sounds exactly like the issue we are having with the
boost/python.  I hadn't reached the point of isolating the problem to
RTLD_LOCAL yet.  If you build two libraries with boost/python and load them
in a python script and try to throw a predefined exception from one of the
two (I forget if it is the first or second), the exception is not caught.

--
Sean Perry
Compiler Development
IBM Canada Lab
(905)-413-6031 (tie 313-6031), fax (905)-413-4839



                                                                           
             Jason Merrill                                                 
             <jason at redhat.com                                             
             >                                                          To 
                                       Dennis Handly <dhandly at cup.hp.com>  
             06/02/2009 03:45                                           cc 
             PM                        mark at codesourcery.com, Sean         
                                       Perry/Toronto/IBM at IBMCA,            
                                       cxx-abi-dev at codesourcery.com        
                                                                   Subject 
                                       Re: [cxx-abi-dev] Deleted virtual   
                                       functions                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Dennis Handly wrote:
>> From: Mark Mitchell <mark at codesourcery.com>
>> other people don't.  For example, when building plugins, you often want
>> each shared library to be completely independent; if my plugin's "class
>> Plugin" is the same as your plugin's "class Plugin", very bad things
happen.
>
> We had to tell another important customer over and over this violated the
> ODR rule.  And our above changes making it hard to hide these classes
> caused them issues.  They didn't want to use the mangled name for many
> classes.  They finally accepted our reasoning, since other vendors had
> to use kludges too.  :-)

Talking about plugins reminds me of a different problem we've run into
on Linux: you have two plugins A and B that both link against the same
shared library C.  A and B are loaded with RTLD_LOCAL to avoid symbol
conflicts.  If there are symbols defined in all three of A B and C,
references in A and C are bound to the definition in A, while references
in B are bound to the definition in B.  If the symbol is a typeid, and B
calls a C function which throws an exception of that type, B can't catch
it because the symbols don't match.

The same issue can come up with static data in inlines or templates,
either data members or function local statics; this case can't be worked
around with string comparison, though it's also less likely to be
encountered.

I've been talking to Ulrich Drepper about ways to deal with this, and
we've decided to go ahead with a solution that makes affected objects
unique through the whole loaded program regardless of RTLD_LOCAL; we
have namespaces to deal with name collisions.  I'm not sure if we
actually want to use this for typeinfos, but I don't see a better
solution for r/w data.

Sorry I didn't mention this to the list sooner.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20090602/f1d82b25/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20090602/f1d82b25/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic22457.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20090602/f1d82b25/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20090602/f1d82b25/attachment-0002.gif>


More information about the cxx-abi-dev mailing list