This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Issue with Latest GDB on AIX with GCC-6.12
- From: Pedro Alves <palves at redhat dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>, Nitish Kumar Mishra <mishra dot nitish dot 88 at gmail dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>, Yao Qi <qiyaoltc at gmail dot com>
- Date: Tue, 31 Jan 2017 13:08:52 +0000
- Subject: Re: Issue with Latest GDB on AIX with GCC-6.12
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnyn0dfXfP8z+G0DFf4JWBZMXreetzg3+xX8_+7LYTmgw6Q@mail.gmail.com> <CAGWvny=e2W+H0VgGv_duZbW5A_LDFo9r9jpcB1U4f9mwwxZ_4A@mail.gmail.com>
On 01/29/2017 01:11 AM, David Edelsohn wrote:
> Note that std::terminate() is called specifically because there was an
> unwind failure and no handler was found in eh_throw.cc in libsupc++
> (part of libstdc++).
Right, that's what makes it look like either an runtime unwinder,
or unwind info bug.
> Is this code trying to propagate an exception through a signal
> handler, in which case GCC MD_FALLBACK_FRAME_STATE_FOR needs to be
> tweaked to find more AIX kernel signal handler signatures.
Nope, it's just normal C++ frames all the way from the throw to
the "catch" that should catch the exception.
(GDB stopped throwing from signal handlers before we flipped
the C++ switch, with:
[PATCH 00/30] Stop throwing exceptions from signal handlers
https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html
)
I'd suggest progressively hacking in "catches" to frames
closer to the throw in question helps identify the frame that
can't be unwound. Like, sprinkling in a few:
try
{
...
}
catch (...)
{
printf ("%s:%d: got here\n", __FILE__, __LINE__)
throw;
}
Thanks,
Pedro Alves