(2) Altering the return address from the current function (where the user
typed "next") is no help as we can be in a try { } block existing already
in the current function. catch { } block in the current function would
catch the exception thrown somewhere during the execution and GDB would
lost the control.
(3) GDB cannot alter the return address to the current function as just it is
created already when the inferior is left running.
.eh_frame section is like .debug_frame section but it has partially different
format (the format is IMO best described by checking the GDB parser
differences against the DWARF-documented .debug_frame format). .eh_frame is
present in each C++ program even if no debuginfos are installed as .eh_frame
is required for the runtime C++ exceptions unwinding. One can check the
.eh_frame content using `readelf -Wwf'. We are interested in `Augmentation:
"...P..."' for the `personality' address (which is contained in `Augmentation
data:' there but this part is not decoded by `readelf').
GDB can find .eh_frame associated with the current function (where "next" is
being run) - it even already has an existing infrastructure for it as it can
unwind frames using .eh_frame (when no .debug_frame is available). There
always exists such .eh_frame for any called function/library in a C++ program.
And GDB can patch in the `personality' function into this .eh_frame to trap
any attempt to call even a catch { } block located in the current function for
the current try { } block we may be in. It will need to put the 'P' character
into the Augmentation string of the CIE associated with the FDE for the
current function and also put some address with a GDB breakpoint at the right
position of the Augmentation data at that CIE.
Unfortunately GDB would have to patch the existing in-memory .eh_frame as
registering a new one using inferior call of __register_frame_info() would
have no effect as the existing .eh_frame would be preferred by
gcc/unwind-dw2-fde.c _Unwind_Find_FDE() (`seen_objects' is preferred over
`unseen_objects').
Another problem are recursive functions - if the current function is later
called again, the unwinding trap there should happen for the toplevel function
call. But this is already being solved during "next" for the placed
breakpoint so this handling needs to be extended even for .eh_frame.