From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-45569-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 119843 invoked by alias); 31 Jan 2017 13:09:06 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 119695 invoked by uid 89); 31 Jan 2017 13:09:05 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=unwound, H*f:CAGWvny, H*i:CAGWvny
X-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Jan 2017 13:08:54 +0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id CAD923A76B0;	Tue, 31 Jan 2017 13:08:54 +0000 (UTC)
Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4])	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0VD8rWS028256;	Tue, 31 Jan 2017 08:08:53 -0500
Subject: Re: Issue with Latest GDB on AIX with GCC-6.12
To: David Edelsohn <dje.gcc@gmail.com>,        Nitish Kumar Mishra <mishra.nitish.88@gmail.com>
References: <CAGWvnyn0dfXfP8z+G0DFf4JWBZMXreetzg3+xX8_+7LYTmgw6Q@mail.gmail.com> <CAGWvny=e2W+H0VgGv_duZbW5A_LDFo9r9jpcB1U4f9mwwxZ_4A@mail.gmail.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>, Yao Qi <qiyaoltc@gmail.com>
From: Pedro Alves <palves@redhat.com>
Message-ID: <21a21388-b1d9-816c-377e-d4e084cc399e@redhat.com>
Date: Tue, 31 Jan 2017 13:09:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAGWvny=e2W+H0VgGv_duZbW5A_LDFo9r9jpcB1U4f9mwwxZ_4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2017-01/txt/msg00054.txt.bz2

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