This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example



----- Original Message -----
From: "Mark Mitchell" <mark@codesourcery.com>

> And, of course, this applies to C++ modules too: I don't want your
> module catching my exceptions just because we both happen to have
> a type with the same name.  Or maybe I do, but I'm not sure unless
> I know what your module is, and whether it means the same thing by
> that type that I do...

Careful, though: that's not the case we're discussing. The case, once
again, is that two libraries lib1 and lib2 loaded with RTLD_LOCAL are both
linked to a third library X in the usual global-symbol-sharing way.
Throwing exceptions between lib1 and X works, but between lib2 and X fails
to work.

Nobody expects to be able to throw exceptions between two shared libs in
general without explicitly linking them together, AFAIK. However, windows
compilers work this way and AFAIK it does NOT cause problems. People tend
to be fairly careful about letting exceptions travel across module
boundaries where they're not intended in any case. Usually entry points in
modules loaded with RTLD_LOCAL are called by "C" code and are not allowed
to throw anyway.

> And here we hit the age-old debate, on which I am usually on the losing
> side.

I hope so <wink>

> My feeling is that a user interface like this

What do you mean by "like this"?

> is just not worth having.
> It is true that these features

Please be specific so that I can understand your position. Which are "these
features"?

> can be useful to some people some of the
> time, and that in careful hands can be deployed appropriately.  It's
> just that we have a lot of problems in GCC due to our corner-case
options;
> we've tacked on options to let all kinds of people do all kinds of
things.
> But, we tend to break those options, and we tend to not document them
> right, and people tend to use them in unintended ways, and so forth and
> so on.  I don't think we serve our users in this way.

There are several reasonable choices for behaviors which would make things
work. None of them would be hard to document or to understand. The
situation now is hard to get right, hard to understand, and hard to test
(because the behavior depends on module load order). Making things work
would be a vast improvement for users, and would make it possible to
program to a reasonably similar mental model for most platforms that
support dynamic linking.

> All that said, I'm surprised that throwing exceptions -- without crossing
> DSO boundaries -- doesn't work.  I'd expect that would work almost by
> accident.

Have you read the rest of the thread? The reasons it doesn't work by
accident have been pretty fully explored; if you're still surprised in
light of that explanation I'd appreciate knowing why because the rest of us
are probably missing something important.

-Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]