Re: Simple exception use-case

[Phil Muldoon <pmuldoon at redhat dot com>]

Daniel Jacobowitz wrote:
> Some pointers for this topic... I've looked at it several times so I
> may be able to give you a head start :-)
>   

Cool, this is exactly the information I need. Thanks for taking the time 
to write it up. I find it useful to work from a base work-flow up, 
simply to put me in the frame of mind of a user.

> On Mon, Jul 28, 2008 at 01:52:25PM +0100, Phil Muldoon wrote:
>   
> > <snip useful info>
> >
> > Raised exceptions may be caught:
> >    catch throw - all exceptions, when thrown
> >    catch throw <exceptname>  - a particular exception, when thrown
> >    catch catch - all exceptions, when caught
> >    catch catch <exceptname>  - a particular exception, when caught
> >     
>
> I suspect the named versions do not work for C++ (iirc they did for
> HP-UX at one time, and/or do for Ada).
>   

I've not been able to do anything with named exceptions. I only brought 
them up as a neat possibility, and they were in the help, so what the 
heck. My primary goal is to get the C++ simple throw/catch understood 
and issues notated first. But it would totally rock if I could break on 
named exceptions in C++ somewhere down the line ;)

>   
> > Well I think it is "throw simple", that is the last line shown. But it  
> > would be neat if the catch would print the actual throw line, like a  
> > simple breakpoint. Shown below:
> >     
>
> Making GDB do this is not too complicated.  There is a caveat - the
> last time I tried it, it broke Eclipse.  Having the debugger stop with
> a frame other than the innermost selected is a little tricky but there
> may be a better way to do it than I tried; there's more state change
> notifications in GDB than there were at the time.
>   

Ugh, the Eclipse breakage is a bummer. From a personal perspective it 
would be neat to see the stop at the throw with the line information.

>   
> > Catchpoint 1 (exception thrown), 0x000000333d0c3d70 in __cxa_throw ()  
> > from /usr/lib64/libstdc++.so.6
> > (gdb) s
> > Single stepping until exit from function __cxa_throw,
> > which has no line number information.
> > Exception: simple exception occurred
> >
> > Program exited normally.
> >
> > Well maybe not.  I'm not sure why I lost control of the inferior.
> >     
>
> GDB has this problem with both longjmp and longjmp-alikes.  Pedro
> nearly fixed the longjmp problem but was, in the end, defeated by some
> complexities of glibc's pointer mangling; you can find discussion in
> this spring's gdb-patches archives.  DWARF unwinding uses a
> longjmp-alike, GCC's __builtin_eh_return, which has the same problem.
>   

Ok this is great info, and good that I stumbled upon it in the first 
base use-case. I was pondering what the longjmp implications were in the 
tasks mail. Now I know ;)

> GDB expects when you step over or out of a function that it can
> shortcut by placing a breakpoint at the return address.  So it has to
> be taught about functions with abnormal control flow.  Reference:
> gcc/unwind-dw2.c:uw_install_context.
>
>   

Thanks

> > gdb simple
> > GNU gdb Fedora (6.8-11.fc9)
> >
> > (gdb) catch catch
> > Function "__cxa_begin_catch" not defined.
> > (gdb) catch throw
> > Function "__cxa_throw" not defined.
> >     
>
> IIRC this is because GDB does not (did not?) use pending breakpoints.
> Try again after starting the program, so libstdc++ is loaded.  If it's
> still broken it's an easy fix.
>   

I'll look at this. The reason I brought it up was the divergence in 
work-flow from Fedora GDB and upstream GDB. I'll tinker with this some 
more. I'm interested if this is a divergence between a patched version 
of GDB, versus upstream, or whether the code in the Fedora GDB is just 
older.

Regards

Phil