[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150409173418.GL6817@brightrain.aerifal.cx>
Date: Thu, 9 Apr 2015 13:34:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Execinfo.h, backtrace is needed.
On Thu, Apr 09, 2015 at 01:28:55PM -0400, Jean-Marc Pigeon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
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.
