Re: Exceptions thrown from framework not caught in application
Re: Exceptions thrown from framework not caught in application
- Subject: Re: Exceptions thrown from framework not caught in application
- From: Steve Baxter <email@hidden>
- Date: Tue, 12 Sep 2006 18:42:32 +0100
Hi Andreas,
On 12 Sep 2006, at 16:40, Andreas Grosam wrote:
On 08.09.2006, at 01:38, Steve Baxter wrote:
I wish Apple would fix this - the fix is a single line of code.
Unfortunately it is not considered to be a bug...
radt://4424486
The biggest problem with this right now is that on 10.3.9 this is
completely broken. If you want to target 10.3.9 and you want to
use RTTI or exceptions across a DSO (module/framework/application)
boundary, you cannot use GCC 4.x.
radr://4535751
If we assume the source code has been correctly decorated with
export directives, what exactly (the more detailed the better) is
the problem (namely the bug/flaw which you refere with "broken") in
the system 10.3.9?
I'm not using export directives, instead all symbols are exported
from all DSOs (GCC_SYMBOLS_PRIVATE_EXTERN = NO)
Does 10.4.x work correctly?
Yes. I believe the bug is in the CRT that comes with 10.3.9. It
fails to correctly resolve duplicate symbols across DSOs under some
circumstances.
It should be noted that in order to enable exception thrown across
DSOs, the symbols for RTTI for that exception classes need to be
instantiated only once in the fully linked application.
Indeed.
Does this problem you refere to occure during static linking, or is
it restricted to dynamically linking via dyld when linking shared
libs, or is it restricted when dynamically binding plugins?
Only when dynamically binding plugins as far as I know.
If possible, please explain it using the following model:
Suppose there is a shared lib B which defines an "exception" class
E. The shared lib B might have undefined references which are
defined in another shared library C. When building lib B we need to
link against shared lib C:
B -> C
(B -> C) now describes the acylic graph of needed objects.
Now, suppose there is a DSO (shared lib or main executable) A in
which the class E should be handled in a catch clause.
1) What is required to build and link all libraries successfully?
What are the appopriate visible attributes for the classes?
It should be noted, that when building A, A may (statically)
link against C.
Can we catch exceptions of type E within code from A?
(differences in 10.3.9 and 10.4.x ?)
2) Suppose, DSO B is a plugin which will be loaded and unloaded
dynamically at runtime.
What is now required to link and build all libs successfully?
What are the appopriate visible attributes for classes?
It should be noted, that when building A, A cannot (statically)
link against C anymore.
Is it still possible to catch exceptions of class E in lib A?
Thank you for your effort to investigate this issue.
Let me explain it this way. Lets have plugins A, B and C. All three
plugins export all their symbols and all three plugins define an
exception E. The plugins do not link to each other (they are all
loaded by some other external entity, lets call it application X,
into the global symbol table). On 10.3.9, if plugin A throws an
exception E that is caught by B, B will not correctly identify it as
an exception of type E. This problem will also occur with other uses
of RTTI such as typeid() and dynamic_cast<>(). On 10.4.x this works
fine.
Note that you still have to jump through some other hoops even on
10.4.x - CFBundle does not do the right thing when loading plugins
that require RTTI to work properly, it loads plugins with private
(local) symbol visibility. This is mostly a reasonable thing to do
as it prevents plugins interfering with each other, however here you
actually want them to interfere with each other so that symbols are
resolved uniquely! The solution to this is to use dlopen
( RTLD_GLOBAL ) to load your plugin (you can then use CFBundle as
well, dlopen() will already have done its magic).
The problem with 10.3.9 and GCC 4 (radr://4535751) is a confirmed bug
- Apple are intending to fix it, though 10.3.9 is increasingly long
in the tooth so it may be that 10.3.9 will be truly dead before the
fix becomes available. If you need RTTI to work reliably across a
DSO boundary on 10.3.9, I believe you will have to use GCC 3 for now.
Cheers,
Steve.
Steve Baxter
Software Development Manager
Improvision
+44-2476-692229
_______________________________________________
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