From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14595 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: libexecinfo with musl Date: Fri, 23 Aug 2019 16:21:44 +0200 Message-ID: <87k1b4rmh3.fsf@oldenburg2.str.redhat.com> References: <20190822030739.GH9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="156547"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14611-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 23 16:22:02 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i1AS1-000eYy-K9 for gllmg-musl@m.gmane.org; Fri, 23 Aug 2019 16:22:01 +0200 Original-Received: (qmail 7356 invoked by uid 550); 23 Aug 2019 14:21:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7338 invoked from network); 23 Aug 2019 14:21:58 -0000 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 23 Aug 2019 14:21:46 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14595 Archived-At: * Rich Felker: > backtrace should not require any "support from libc". My guess at > what's happening is that it fails to trace past main's stack frame > back into the call point in libc startup code, since libc lacks unwind > info. A working backtrace implementation needs to be prepared for this > possibility and stop if it reaches back to an address without unwind > info. Depending on the architecture, this is impossible because some ABIs mandate that the unwinder behaves in certain ways (other than stopping) if a frame does not have explicit unwind information. For example, they could assume that the frame has a frame pointer, or that the stack pointer has not been changed. For example, my understanding is that for POWER, the unwinder must assume that the function has a back chain if the function lacks explicit unwind data. Thanks, Florian