[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
