Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Apr 2015 13:34:18 -0400
From: Rich Felker <>
Subject: Re: Execinfo.h, backtrace is needed.

On Thu, Apr 09, 2015 at 01:28:55PM -0400, Jean-Marc Pigeon wrote:
> Hash: SHA1
> Hello,
> Noticed today, musl doesn't provide execinfo.h
> nor backtrace function.
> Reading mailling list as backtrace is a not needed
> function as "gdb can do it".
> I beg to disagree.
> There is many time where backtrace capabilities
> are handy.
> Ex: within a daemon you want to detect and trace
> a memory leak origin. This can not be done within
> a testbench, as the leak is small and occur
> once in a (very long) while.
> I understand there is no "standard" defining
> the way to implement it.
> What is the musl designers position,
> never ever backtrace to be implemented or
> this could be good for real production
> program.
> May be there is a way to get backtrace
> capabilities I overlooked within musl?

I believe there's a third-party libbacktrace that might work with
little or no modification. The function is not appropriate for
inclusion in musl both for the reasons discussed in the past and for
important technical reasons, including at least:

- It would require musl either static link with gcc's libgcc_eh or
  libunwind, neither of which is acceptable, or that we implement our
  own dwarf interpreter, which is major scope creep.

- It would require that at least part of musl be built with eh_frame
  unwind information.

With a third-party library all of these issues are isolated from musl
and only affect people using the backtrace library.


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.