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: Andreas Grosam <email@hidden>
- Date: Wed, 27 Jul 2005 15:29:42 +0200
On 27.07.2005, at 12:06, Zachary Pincus wrote:
Andreas,
Thanks for your help in tracking down this issue.
Well, i created a test project in order to investigate this. I created
two shared libs, the first one defining a class hierarchy, and the
second shared lib defines one class inheriting from another one defined
in shared lib 1.
I tried out different export settings and dynamic cast and try/catch in
the main app.
Firstly, as far as i have tested, the compiler and linker works as
expected.
The linker is also pretty "smart", in that it complains about any
missing RTTI symbols or VTs. So, you can't "forget" to export a certain
class, because otherwise the linker would complain about a missing
symbol (e.g. "Undefined Symbols: typeinfo for A") and not link the
program.
I could also not manage to successfully compile something which would
then not work as expected. I tried many different cases, which all did
either compile/link/work successfuly, or would not link.
I did not tested templates and cross casts, yet. Maybe there is a
problem there.
Well, the only other thing i can immaging is, that the compiler is just
plain right ;-)
If you have a class which inherits protected/private from another base
class, a dynamic cast may fail.
Regards
Andreas
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