This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: frame unwinding patches
- From: Ulf Hermann <ulf dot hermann at qt dot io>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: <elfutils-devel at sourceware dot org>
- Date: Thu, 20 Apr 2017 11:26:31 +0200
- Subject: Re: frame unwinding patches
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=qt.io;
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qtcompany.onmicrosoft.com; s=selector1-qt-io; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QuJnFLIexzddKPuSsajlY1ZYerjs77kzRS/esHGaFgI=; b=FCGHMdRjD1XLN8XE28ZmA/VHqA528ke7XG9fJ6/SsHsVEq82hgoBPogApDENbgW2QrvFIwyfqu9ExwRfSi6QoSu7m2zXfuqx7+LNDh+NwzjRYtyMkaBULcnZDAwUkzSHLLLzGkjUeBLkz2C1D1I4bgIdSWedR1pxvycsu1+dHjY=
- References: <1487201610-8381-1-git-send-email-mark@klomp.org> <3915502.JGE1jdPxOT@milian-kdab2> <75e83a7d-b372-3436-ba7a-3a49900e92dd@qt.io> <20170403211516.GB9584@stream> <1491560851.8380.162.camel@klomp.org> <ca107eef-9f1a-b6d6-3fe5-81470eb4be4e@qt.io> <1492631295.21701.180.camel@klomp.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> That might just mean that the testcase is slightly unrealistic.
> Getting a reliable backtrace through signal handlers when not having
> full CFI is probably not something we can expect to work. That doesn't
> mean having a frame pointer based fallback is a bad thing. We probably
> should find a more realistic testcase. And maybe in the future add an
> interface to allow people to unwind through "pure CFI" or mixed mode
> with frame markers that tell the caller whether the registers can be
> trusted or not.
The x86_64 case already works with the test case I sent. Maybe we can accept that one before the others. The aarch64 case almost works, but seems to generally duplicate the first entry it unwinds by frame pointer after unwinding anything by CFI. That should be fixable. I will research it and post a follow up patch. The 32bit arm case is a horrible mess and we may indeed need to lower our expectations for that one. Or maybe I can find a raise() that follows the same frame conventions as the gcc I'm using ...
br,
Ulf