From owner-freebsd-hackers@freebsd.org  Fri Jul  7 11:44:47 2017
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91AF7DA0EB4
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Fri,  7 Jul 2017 11:44:47 +0000 (UTC) (envelope-from joerg@bec.de)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net
 [217.70.183.195])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 50C8B76DB8;
 Fri,  7 Jul 2017 11:44:46 +0000 (UTC) (envelope-from joerg@bec.de)
Received: from britannica.bec.de
 (p200300D2ABC87B104639C4FFFE599710.dip0.t-ipconnect.de
 [IPv6:2003:d2:abc8:7b10:4639:c4ff:fe59:9710])
 (Authenticated sender: joerg@bec.de)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B9FA4A80F1;
 Fri,  7 Jul 2017 13:44:43 +0200 (CEST)
Date: Fri, 7 Jul 2017 13:44:35 +0200
From: Joerg Sonnenberger <joerg@bec.de>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: Conrad Meyer <cem@freebsd.org>, Marc Branchaud <marcnarc@xiplink.com>,
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject: Re: libexecinfo backtrace() in a signal handler
Message-ID: <20170707114435.GA5034@britannica.bec.de>
Mail-Followup-To: Konstantin Belousov <kostikbel@gmail.com>,
 Conrad Meyer <cem@freebsd.org>,
 Marc Branchaud <marcnarc@xiplink.com>,
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com>
 <CAG6CVpXMMWYniDUOGXakO=qiU+BBWCcTEknBjS+uQcAsPYB1VQ@mail.gmail.com>
 <20170706231622.GA26699@britannica.bec.de>
 <20170707053744.GM1935@kib.kiev.ua>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170707053744.GM1935@kib.kiev.ua>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 11:44:47 -0000

On Fri, Jul 07, 2017 at 08:37:45AM +0300, Konstantin Belousov wrote:
> On Fri, Jul 07, 2017 at 01:16:22AM +0200, Joerg Sonnenberger wrote:
> > On Thu, Jul 06, 2017 at 03:58:04PM -0700, Conrad Meyer wrote:
> > > Signal handlers use a special stack frame that libexecinfo is too
> > > simple to understand.  To get a stack from a signal handler, you might
> > > want to use libunwind instead.
> > 
> > Actually, that's not the problem. The problem is that nothing registers
> > the necessary unwind data.
> 
> Actually, that's not the problem.  Libunwind port on FreeBSD knows how
> to detect signal trampolines, either with the direct help from kernel,
> or using some heuristic by parsing instructions, on (much) older kernels.

But the original question was about libexecinfo and the Itanium unwinder
it is using. That would be able to unwind past signal frames iff the
proper annotation was registered. I haven't had time to do that for
NetBSD, but it is certainly the original problem.

Joerg