[Mingw-users] Re: Trapping failed assertions in gdb?

[Dan M. <do....@sp...>]

Following up on my post, in case anyone else is wondering how to do this...

After disassembling some test programs, I found a reasonable way of
intercepting unhandled exceptions: Simply set a breakpoint at
std::terminate(). To catch *all* throws, set a breakpoint at &*__cxa_throw.

The compiler generates a label __cxa_throw when it compiles a throw
statement. I thnk this label is an indirect reference to some other code,
rather than a function. (I'm a bit shaky on the Intel assembler code format
used by gcc and gdb; pointers to an online quick reference would be
appreciated.) This code in turn calls std::terminate() if no handler is
found.

"Dan Muller" <do....@sp...> wrote in message
news:alhgh0$loj$1...@ma......
> Following up, somewhat belatedly ... my previous reply seems to have
gotten
> lost.
>
> "Greg Chicares" <chi...@mi...> wrote in message
> news:3D7...@mi......
> > Dan Muller wrote:
> > >
> > > I'm trying to debug a small program built with mingw, and I can't
figure
> > > out how to get the debugger to stop when an assertion fails.
> >
> > This will work: write your own assertion macro, and have
> > it call a function in a .cpp file (where breakpoints
> > often work better than in a header file).
>
> This would be possible but a little difficult, because the assertions are
> failing in third-party code (a Boost library). Instead, I found that I
could
> write my own replacement for the function which handles failed assertions,
> with this signature:
>
> extern "C" void _assert (const char* err, const char* file, int line)
>
> I'm linking statically; I'm not sure if this would work if I were linking
to
> shared libraries.
>
> Unfortunately, this worked in 2.95.3, but doesn't appear to work anymore
in
> 3.2. I don't know what the problem is yet.
>
> >
> > > If I try to specify "catch throw" in Insight's console window, I get
> > > "Error: No run-time support for this", which makes me think that I may
> > > be building something wrong, or using the wrong libraries.
> >
> > This will work: throw your own exception, perhaps derived
> > from one of the standard exception classes, and put its
> > constructor in a .cpp file where you can set a breakpoint.
> >
>
> Again, it would be difficult to follow this advice; the code throwing the
> exceptions is in a third-party library. I tried installing a default
> exception handler and setting a breakpoint there. This didn't work at all
in
> 2.95.3, but does work in 3.2. Unfortunately, by the time the handler is
> called, it's really too late. The stack at the site of the throw has
already
> been unwound.
>
> In some GDB documentation, I saw a recommendation to set a breakpoint at
> __raise_exception. This doesn't seem to be defined in 3.2, AFAICT. I also
> searched through the MinGW runtime sources, but couldn't locate a function
> that handles the throwing of exceptions. I'd look through the C++ library
> source, but I couldn't tell which package at the MinGW SourceForge site
> contains it, if any. Pointers are welcome.
>
> BTW, the version of GDB packaged with MinGW 2.0 gives me the same error
when
> I issue the command "catch throw".
>
> > > Am I running into limitations of gcc 2.95.3-6, or mingw, or of the
> > > particular builds of the libraries that come with mingw?
> >
> > I've never had much luck except by falling back on the
> > simple-minded approaches above.
>
> There's got to be a better way. :-) Any and all pointers welcome.
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>