Bug 9599 - catch catch and catch throw restore control of the inferior inside libstd exception handler and throw code.
Summary: catch catch and catch throw restore control of the inferior inside libstd exc...
Status: ASSIGNED
Alias: None
Product: gdb
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: archer
Depends on:
Blocks:
 
Reported: 2008-08-05 16:28 UTC by Phil Muldoon
Modified: 2013-02-22 16:05 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Muldoon 2008-08-05 16:28:01 UTC
[Converted from Gnats 2494]

catch catch - when the inferior enters an exception handler (in C++) "catch catch" returns control inside the __cxa_begin_catch code in libstdc++ library.

catch throw -  when the inferior throws an exception (in C++) "catch throw" returns control inside the __cxa_throw code in libstdc++ library.

Both of these occur as the "catch catch" and "catch  throw" operate by placing a breakpoint in __cxa_begin_catch and __cxa_throw libstdc++ functions respectively. While this is technically within "the code", it would be a better user experience to return control of the inferior at the line of the catch or throw, before it has executed the catch of throw.

Release:
unknown
Comment 1 Tom Tromey 2013-02-20 21:56:52 UTC
I don't think there is a very good way to do this directly,
but it could be faked by installing a frame filter that
notices that the newest frame is __cxa_begin_catch and that
the PC is where "catch catch" placed it.
Then, the filter can simply elide the first frame.

However, this would yield somewhat strange results.
First, it isn't clear whether a frame filter can actually
elide the first frame.
Second, this would yield a situation where "bt" would report
the selected frame as the user's code, but where the
actual selected frame would be in libstdc++; so things
like "info locals" would fail.
I think that fixing this requires the next step of frame filters, namely
integration with frame selection.