Re: How is this not a complier error? (dynamic casting problem)
Re: How is this not a complier error? (dynamic casting problem)
- Subject: Re: How is this not a complier error? (dynamic casting problem)
- From: Zachary Pincus <email@hidden>
- Date: Wed, 27 Jul 2005 03:06:35 -0700
Andreas,
Thanks for your help in tracking down this issue.
Second, you are right to wonder if the problem has to do with DSO
boundaries. My attempts to make complete test cases (as you
suggest below) did not re-create the bug. In fact, I *only* see
the error if the Image object was passed across a DSO boundary. If
I make a new one in situ, no error.
If you define a class which later may be an operand in a
dynamic_cast operator which is called from within another DSO - or
if this is a class which is thrown in an exception and the catch
expression is in another DSO or crosses DSOs, you should (need to)
export RTTI symbols.
RTTI will be exported only when the class is exported (gcc-4.0.0).
(see below how to ensure to export the class).
Ugh; my code has too many DSO boundaries.
DSO 1 contains "base class" (non-template) code
Templated "image" objects which inherit from the base class are
created in DSO 2 and passed to DSO 3, where they are processed, and
where the dynamic_cast fails. If these objects are created in DSO 3,
the cast does not fail.
There is no explicit export information in my code, but there don't
seem to be any gcc visibility flags set. I am in the process of
double-checking this and adding the EXPORT macros you suggest. I will
report back on that issue.
Is there a better run-time check to make sure that the RTTI
information was properly exported?
hm, typeid may access the mangled name of the type, which would be
not there if RTTI is not there.
Yes, typeid is able to get the mangled name of the type with no
problems. Since the code I'm dealing with is pretty hairy and some of
it is made with an external build tool, being able to check at
runtime if the RTTI information is exported would be very valuable.
Is there any way I can be sure that the fact that typeid works means
that the symbol was exported?
You can also use the nm tool, to check which symbols have been
exported. For gcc-4 RTTI symbols start with _ZTI.
Please read the man page for nm and make some tests with small
sources.
I'll work on this. It's too bad the codebase I'm working with is
hairy (multiple DSOs, templates inheriting from non-templates across
DSO boundaries, etc), because that makes it hard to isolate which
thing is causing the problem. Ugh.
Anyhow, in my (oh so abundant) extra time, I'll try to either come up
with a complete test case, or at least narrow down the scope of the
issue. Please let me know what I can do to help! (Already in the
queue: making sure symbols are exported, verifying this with nm,
verifying this at run-time. Anything else?)
Thanks,
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden