This is the mail archive of the
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Geoff Keating <geoffk at geoffk dot org>
- To: mark at codesourcery dot com
- Cc: zack at codesourcery dot com, jakub at redhat dot com, aldyh at redhat dot com, gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Fri, 8 Nov 2002 11:30:21 -0800
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
- References: <firstname.lastname@example.org>
> Date: Thu, 07 Nov 2002 15:34:53 -0800
> From: Mark Mitchell <email@example.com>
> > (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 <firstname.lastname@example.org>