This is the mail archive of the 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: [basic-improvements] try/finally support for c/c++ - more tests

> Date: Thu, 07 Nov 2002 15:34:53 -0800
> From: Mark Mitchell <>

> > (a) slow down normal C++ unwinding, because you have to keep looking
> >     for runtime-installed cleanups?  and
> That's pretty much a total non-issue, but it's true.  It would be a
> quick check, and exceptions are expensive anyhow; as a percentage of
> EH-handling cost, let alone as a precentage of program time, this
> would be free.

This would need to be measured...

There would also be ABI issues, of course, since this is a global list
shared by everything.

> > (b) still require unwinding data for the C code?
> Only a very ittle.  I'm not sure you'd even need the typical
> data; just enough to figure out what function invocation you're in.
> You certainly wouldn't need per-block-including-cleanup information,
> which is what would happen with try-finally.
> The key difference from try/finally in this respect is that the
> pthread_cleanup_push interface takes a function pointer and an argument;
> there's noting in there to allow you to access local variables, etc.
> So, you don't need to really unwind the frame; you just need to know
> that you need to call the function.

How do you handle the case of

C++ (with destructor) -> C -> C++ -> cancellable function

if the C frame never calls pthread_cleanup_push?  No, you have to have
unwinding information for all stack frames.

In fact, you might want to think about what the code is going to have
to do for

C++ (with destructor) -> C (with cleanup) -> cancellable function

after the cleanup in the C code, there'll need to be some way to
`rethrow' an exception which may never have been thrown in the first

It's worth pointing out that DWARF2-based cleanup information is
likely to be smaller than each entry in this global list (let alone
the code to add to the global list), and is allocated statically
per-function at compile-time rather than dynamically
per-function-invocation at runtime.

- Geoffrey Keating <>

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