Opened 16 years ago

Last modified 3 years ago

#1259 new bug

Fix gcc 2.95.3 Type Info Functions

Reported by: bonefish Owned by: bonefish
Priority: normal Milestone: R1.1
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #6963, #8133
Platform: All

Description (last modified by bonefish)

Currently the type info functions for __si_type_info and __class_type_info generated by gcc 2.95.3 are calling the base class(es) type info function(s), but instead of using the return value, refer to the base class type info(s) separately. This can cause problems with shared objects generated by older compilers (e.g. the BDirectWindow type info in, since they can contain a type info without a type info function and a type info function of a library loaded later could therefore use the uninitialized one from the old library.

A fact contributing to the problem is that everything is linked with -Bsymbolic (thus disabling symbol preemption), which makes a type info function always initialize and return the type info defined in the same shared library instead of one defined in a library loaded earlier.

The place where to fix the bug is gcc/cp/rtti.c. expand_si_desc() is responsible for creating __si_type_info and expand_class_desc() for __class_type_info type info functions.

The naive approach to move the "get_typeid_1(type)" into the "elems" initialization in expand_si_desc() doesn't work, BTW.

Change History (8)

comment:1 by scottmc, 14 years ago

Was this worked on in the recent gcc update?

in reply to:  1 comment:2 by bonefish, 14 years ago

Replying to scottmc:

Was this worked on in the recent gcc update?


comment:3 by bonefish, 12 years ago

Description: modified (diff)
Version: R1/pre-alpha1R1/Development

#6963 is another instance of this problem.

comment:4 by bonefish, 12 years ago

Blocking: 6963 added

(In #6963) The main cause is that has apparently been built under BeOS. It contains a type info for std::exception, but no type info function. This triggers the issue described in #1259.

The likely reason why the issue didn't show in earlier revisions is the second part of hrev39375. It's actually not even directly related to the weak symbol or symbol preemption features. It just changes the symbol resolution order to one that should be somewhat more robust when add-ons are involved. It could be reverted for gcc 2, but that would only fix this particular situation and might break using your library in a different situation instead. So I don't think there's much point in doing that.

Possible solutions for your problem:

  • Preferred: Fixing #1259.
  • Rebuilding under Haiku.
  • Could work: Build your application under BeOS. This would trigger Haiku's runtime loader's compatibility mode which might work around the issue.

Closing as duplicate of #1259.

comment:5 by korli, 11 years ago

Blocking: 8133 added

(In #8133) I suspect it's a duplicate of #1259

comment:6 by ttcoder, 11 years ago

Blocking: 7785 added

comment:7 by stippi, 9 years ago

Blocking: 7785 removed

comment:8 by pulkomandy, 3 years ago

Milestone: R1R1.1
Note: See TracTickets for help on using tickets.