[haiku-bugs] Re: [Haiku] #1259: Fix gcc 2.95.3 Type Info Functions
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Wed, 08 Dec 2010 22:29:51 -0000
#1259: Fix gcc 2.95.3 Type Info Functions
---------------------------+------------------------------
Reporter: bonefish | Owner: bonefish
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Build System | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Has a Patch: 0
Platform: All | Blocking:
---------------------------+------------------------------
Changes (by bonefish):
* version: R1/pre-alpha1 => R1/Development
Old description:
> 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 libgame.so).
>
> The place where to fix it 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.
New description:
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
libgame.so), 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.
--
Comment:
#6963 is another instance of this problem.
--
Ticket URL: <http://dev.haiku-os.org/ticket/1259#comment:3>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
