libexecinfo with musl

libexecinfo with musl

[Guillaume Quintard]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

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 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.

Thanks!

-- 
Guillaume Quintard

[-- Attachment #2: Type: text/html, Size: 1051 bytes --]

Re: libexecinfo with musl

[Rich Felker]

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

Re: libexecinfo with musl

[Florian Weimer]

* 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

Re: libexecinfo with musl

[Guillaume Quintard]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Hi all,

thank you for your response, I do have a couple of follow-up questions.

* Rich Felker:

> It "requires" backtrace? For actual operation, or for printing stack
> traces in the event of a crash?

The latter, but it's not really my place to question that. It works on
other platforms, so I'd like to achieve parity.

> backtrace should not require any "support from libc"...

To be fair, I'm a bit out of my depth here. From what I see, the lib is
relying on compiler builtins, and they just just fall on their face.
I'm using gcc in both cases, so I'm sure there's some magic involved
somewhere, but I really can't tell where.

* Florian Weimer:

Arch is x86_64, so nothing funky here, and it works on glibc. So, no clue.

* Tuan Hoan:

> We use libexecinfo, not sure if it helps your case.

Thanks for that. I guess my question on that on is: it compiles, but that
is actually run without crashing?

Again, thank you all for having taken the time to read and reply.

-- 
Guillaume Quintard

[-- Attachment #2: Type: text/html, Size: 1646 bytes --]

Re: libexecinfo with musl

[Tuan Hoang]

On 8/26/19 10:56 PM, Guillaume Quintard wrote:
> * Tuan Hoang:
> 
>> We use libexecinfo, not sure if it helps your case.
> 
> Thanks for that. I guess my question on that on is: it compiles, but
> that is actually run without crashing?
> 
> Again, thank you all for having taken the time to read and reply.
> 
> -- 
> Guillaume Quintard

Yes, it works, so far.

Re: libexecinfo with musl

[Guillaume Quintard]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

On Wed, Aug 28, 2019 at 1:16 AM Tuan Hoang <tmhoang@linux.ibm.com> wrote:

> Yes, it works, so far.
>

Thanks, that's interesting. Unfortunately, I noticed that the architectures
aren't the same, so it probably doesn't make sense to compare those.

[-- Attachment #2: Type: text/html, Size: 580 bytes --]

Re: libexecinfo with musl

[Tuan Hoang]

We use libexecinfo, not sure if it helps your case.

https://git.alpinelinux.org/aports/tree/main/s390-tools/APKBUILD#n49
https://git.alpinelinux.org/aports/tree/main/libexecinfo/APKBUILD

On 8/22/19 1:32 AM, 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 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.
> 
> Thanks!
> 
> -- 
> Guillaume Quintard