aboutsummaryrefslogtreecommitdiff
path: root/libiberty/strsignal.c
diff options
context:
space:
mode:
authorAlexandre Oliva <oliva@adacore.com>2019-08-02 18:46:51 +0000
committerAlexandre Oliva <aoliva@gcc.gnu.org>2019-08-02 18:46:51 +0000
commit5d733372faa97c1c3943a20a252d000db37c738b (patch)
tree9c33de25ac3ceb1916f205d3475222ff71a38272 /libiberty/strsignal.c
parent59e01f364927e66c0bb1ebc22c401cf2630616c0 (diff)
downloadgcc-5d733372faa97c1c3943a20a252d000db37c738b.zip
gcc-5d733372faa97c1c3943a20a252d000db37c738b.tar.gz
gcc-5d733372faa97c1c3943a20a252d000db37c738b.tar.bz2
rework Ada EH Machine_Occurrence deallocation
Introduce exception handler ABI #1 to ensure single release, no access after release of reraised Machine_Occurrences, and no failure to re-reraise a Machine_Occurrence. Unlike Ada exceptions, foreign exceptions do not get a new Machine_Occurrence upon reraise, but each handler would delete the exception upon completion, normal or exceptional, save for the case of a 'raise;' statement within the handler, that avoided the delete by clearing the exception pointer that the cleanup would use to release it. The cleared exception pointer might then be used by a subsequent reraise within the same handler. Get_Current_Excep.all would also expose the Machine_Occurrence to reuse by Reraise_Occurrence, even for native exceptions. Under ABI #1, Begin_Handler_v1 claims responsibility for releasing an exception by saving its cleanup and setting it to Claimed_Cleanup. End_Handler_v1 restores the cleanup and runs it, as long as it isn't still Claimed_Cleanup (which indicates an enclosing handler has already claimed responsibility for releasing it), and as long as the same exception is not being propagated up (the next handler of the propagating exception will then claim responsibility for releasing it), so reraise no longer needs to clear the exception pointer, and it can just propagate the exception, just like Reraise_Occurrence. ABI #1 is fully interoperable with ABI #0, i.e., exception handlers that call the #0 primitives can be linked together with ones that call the #1 primitives, and they will not misbehave. When a #1 handler claims responsibility for releasing an exception, even #0 reraises dynamically nested within it will refrain from releasing it. However, when a #0 handler is a handler of a foreign exception that would have been responsible for releasing it with #1, a Reraise_Occurrence of that foreign or other Machine_Occurrence-carrying exception may still cause the exception to be released multiple times, and to be used after it is first released, even if other handlers of the foreign exception use #1. for gcc/ada/ChangeLog * libgnat/a-exexpr.adb (Begin_Handler_v1, End_Handler_v1): New. (Claimed_Cleanup): New. (Begin_Handler, End_Handler): Document. * gcc-interface/trans.c (gigi): Switch to exception handler ABI #1. (Exception_Handler_to_gnu_gcc): Save the original cleanup returned by begin handler, pass it to end handler, and use EH_ELSE_EXPR to pass a propagating exception to end handler. (gnat_to_gnu): Leave the exception pointer alone for reraise. (add_cleanup): Handle EH_ELSE_EXPR, require it by itself. From-SVN: r274029
Diffstat (limited to 'libiberty/strsignal.c')
0 files changed, 0 insertions, 0 deletions