From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14589 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: libexecinfo with musl Date: Wed, 21 Aug 2019 23:07:39 -0400 Message-ID: <20190822030739.GH9017@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="23143"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14605-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 22 05:07:55 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 1i0dS7-0005vD-7C for gllmg-musl@m.gmane.org; Thu, 22 Aug 2019 05:07:55 +0200 Original-Received: (qmail 15413 invoked by uid 550); 22 Aug 2019 03:07:52 -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 15392 invoked from network); 22 Aug 2019 03:07:51 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14589 Archived-At: On Wed, Aug 21, 2019 at 05:32:44PM -0700, Guillaume Quintard wrote: > Hi, > > Apologies if this has already been answered before, information is a bit > hard to find on the topic. > > This is what brings me here: > https://github.com/mikroskeem/libexecinfo/issues/2 > > I'm trying to build and run a bigger program (varnish) that requires > backtrace(), and while it compiles, executing backtrace() results in a > segfault. It "requires" backtrace? For actual operation, or for printing stack traces in the event of a crash? The latter is highly inadvisible as it increases attack surface dramatically; if it's only needed for the latter this functionality should just be patched out. > It looks like the function __builtin_frame_address doesn't really > do what it should. > > It's apparently a builtin function from the compiler, but I sort of > understood it also requires some support from the libc. If that's the case, > would someone care to explain the specifics to help us decide if we should > just cut the backtrace() feature from varnish on musl, or if we should work > towards feature parity. 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. Perhaps it's trying to use frame pointers instead (also not present), wrongly misinterpreting non-frame-pointer data in %rbp as a frame pointer, and blindly following that without validating it... Rich