This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: operator==() of the type_info class


On Thu, Oct 04, 2001 at 02:12:39PM +0000, Jörg Budischewski wrote:
> Hi,
> 
> my name is Joerg Budischewski, I am a Sun Microsystems employee working 
> on OpenOffice (see http://www.openoffice.org) / StarOffice. I work on 
> UNO,  the openoffice component model.
> 
> There is currently some effort underway to port the linux build of 
> openoffice from gcc 2.95.2 to gcc 3.01. The results of the build are 
> currently very promising (some shared libraries have shrinked in size by 
> 50-60%, you have done a great job !), though I can't give a final 
> statement as the build has not finished yet (we e.g. need to change lots 
> of code lines due to the harder check for exception specifications).
> 
> However, we have run into a problem I would like to discuss here.
> 
> The throwing of exceptions via shared library boundaries only works, when 
> the shared library exports the exception's typeinfo symbol. This is due 
> to that the type_info::operator==() is implemented by comparing the 
> type_info-instances-pointers instead of comparing the type-names. 

That's what the new ABI sais.

> In the version 2.95.2, there was an additional strcmp() for the names 
> after the pointer comparision. 
> 
> In our case, we want to limit the exports of shared libraries to the 
> absolute minimum (which are 3 C-functions for each shared library in our 
> case). So every library has its own instance of the exception-typeinfo. 
> This leads to the unexpected exception.
> 
> Though we could solve this by additinal exporting every type_info 
> exception symbol, there may still arise a problem when the first library 
> offering a certain exception symbol gets unloaded (dlclose()). The 
> type_info for this certain type is then not available for other libraries 
> anymore which may lead to segfaults.

Proper dynamic linker should create a relocation dependency on the library
and not allow it to be dlclosed unless all references to it are dlclosed
too. glibc should do this right, if you find any problems, please report
them.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]