Re: Exceptions thrown from framework not caught in application [Workaround]
Re: Exceptions thrown from framework not caught in application [Workaround]
- Subject: Re: Exceptions thrown from framework not caught in application [Workaround]
- From: Andreas Grosam <email@hidden>
- Date: Thu, 14 Sep 2006 17:18:03 +0200
On 14.09.2006, at 15:00, Andreas Grosam wrote:
On 14.09.2006, at 00:55, Steve Baxter wrote:
On 13 Sep 2006, at 22:54, Andreas Grosam wrote:
Unfortunately, i can confirm now, that this issue also happens with
shared libraries, which comprise a legal application. I created the
application in Xcode 2.4 on 10.4.7.
On 10.4.x, the application works correctly. On 10.3.9 it fails.
It is pretty much obvious that the dynamic linker on 10.3.9 is
unable to merge several definitions of coalesced weak symbols. For
RTTI this kind of symbol will be produced quite often - but not
always, the alternative is to use undefined references.
More specifically, if a RTTI symbol (in this example for the class
Error) is defined in more than one DSO like this:
000041c8 (__DATA,__const_coal) weak external __ZTI5Error
the dyld of 10.3.x fails to coalesce the definitions into a single
one, and hence the ODR will be violated.
I failed also to find a workaround so far, like forcing to create
the RTTI definition where the class ctor is defined, and
subsequently *reference* to existing RTTI symbols instead creating
new definitions in the calling DSO. However the compiler preferes to
create new definitions anyway,
Eventually, I found a workaround, which works for shared libraries. (I
would like to exclude plugins so far, since it is not clear how plugins
share such facilities at all. But later.)
The idea is to avoid multible definitions of RTTI symbos in several
DSOs. Notice, that during building of a certain DSO, the acyclic graph
of needed objects must be known by the linker. This will be ensured
through specifying to link against all shared libraries that contain
the definitions to the referenced symbols.
If there is only one definition of the RTTI symbols in a set of DSOs in
the fully linked application, the flaw in dyld in 10.3.9 wouldn't have
an effect.
In order to ensure that only one definition of an RTTI symbol is
generated for a set of DSOs comprising the acyclic linked graph of
needed objects, it must be ensured that a so-called "trigger function"
is defined for that class.
A trigger function is the first virtual member function which is
declared non-pure and non-inline. If the compiler detects such a
function, it defines the associated RTTI symbols in the same module
where the trigger function is defined. Subsequent references to the
RTTI symbols - even from outside the DSO where they are defined - will
now use references instead of their own (weak coalesced) definitions.
For the trigger funciton, the class' dtor might be choosen for that
purpose, although any other member function would do the trick as well.
If you use a dummy function though, you need to ensure that this
function will not be dead-stripped, and in turn the RTTI symbols as
well (needs further investigation).
Notice also, that for each exported class a trigger function has to be
defined. It is not sufficient, that this is defined in a base class
only.
Say we have a class which is subject to be exported and which RTTI
symbols will be referenced from within other DSOs:
// file Error.h
#define EXPORT __attribute__((visibility ("default")))
class EXPORT Error
{
public:
Error(int e);
virtual ~Error(); // must be defined. Provides the "trigger
function".
...
private:
int _e;
};
// file Error.cpp
#include "Error.h"
Error::Error(int e) : _e(e) {}
Error::~Error() {}
This workaround has some implications, though. Firstly, the exported
class will become a virtual class, and there is always a vtable
constructed and defined along with the RTTI symbols which might be
undesired.
Well, I hope that this workaround might be at least helpful and solves
some issues. I would appreciate it, if you could report your own
experience with this workaround, thanks.
Andreas
Andreas
Yep, that's the one...
If there is a flaw in dyld on 10.3.x, this would also mean, that
dymically loaded DSOs (aka plugins) may not work correctly, even when
they use dlopen() (with any flags specified) or other interfaces
(NSBundle) since these are clients of dyld.
The only reasonable solution seems to be that Apple provides fixed
system libraries, which are available as a regular update, or may be
installed manually.
So, are there any official statements from Apple?
Andreas
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:
email@hidden
This email sent to email@hidden
_______________________________________________
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