This is the mail archive of the gcc-patches@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: [RFC] C++ vs forced unwinding


>In C, -fforced-unwind-exceptions is the same as -fexceptions (since
>there are no ordinary exceptions), right?

Really? I must be confused. Perhaps somebody can set me straight.

How does -fsjlj-exceptions and --enable-sjlj-exceptions fit into this? I
was under the impression that some targets (m68k, say, but others) still
don't have call frame exception capability. What would
-fforced-unwind-exceptions mean for these ports?

(As an aside, why can't their be symmetric flags like
-funwind-exceptions/-fsjlj-exceptions, where -fexceptions == the default
configured behavior, and -fno-exceptions == sorry sucker)

>So, we're now back to the state where C shared libraries have to have
>unwind tables, if that shared library might ever be used in a threaded
>program, right?  (And calls a cancellable function, I suppose.)

Boo.

>I still feel like we should be able to do better.  If, for example,
>calls to the shared library from other code went through some kind of
>thunk (use the PLT?), we could just create a dynamic catch entry at that
>point (as for longjmp), rather than having to instrument each function. 
>That might be a good for-future-expansion direction.

I'm hoping Jason can comment on this.

-benjamin


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