[LLVMdev] trouble understanding value in dwarf exception mechanism

edA-qa mort-ora-y eda-qa at disemia.com
Wed Apr 24 22:38:26 PDT 2013


I'm having trouble understanding the value in the way exceptions are
handled on Linux, the dwarf/system V ABI exception spec. The mechanism
allows for both cleanup routines and catch handlers, where by cleanup
handlers don't stop the search for a normal handler. The personality
function (I guess no longer part of the standard, but a C++ thing) can
also compare types of the landingpads.

I'm having trouble understanding a few points. I would like to
understand since I have exceptions in my language as well and want to
make effective use of the model.

1. The way basic blocks come together often means you can have embedded
try/catch handlers without an intervening function call. You can't have
multiple landingpads without an intervening invoke thus one block needs
to branch/include the other handler. This appears to result in the need
to check the types of exceptions in the landingpad. This seems wasteful
to check the types in both the personality and the landingpad.

2. Cleanup landingpads, in the general case, will need to call
functions. Not knowing what is in these functions one must assume they
could in turn have their own exception flow: they have a try/catch but
don't allow exceptions to escape. The ABI mechanism though seems like
only one exception at a time can be in progress. This would mean that
cleanup code would have to register as catch handlers and rethrow the
exception -- they cannot be "cleanup" routines according to the standard.

In all I don't see why the current approach is better than simply
treating all landingpads equally in the personality. Each landingpad
would do its own type checking and rethrow or continue as appropriate.
That is, no cleanup routines, and no type matching in the personality.

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130425/df0a30a4/attachment.sig>


More information about the llvm-dev mailing list