Date: Wed, 21 Aug 2019 23:07:39 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: libexecinfo with musl 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.