Re: [boost] Stacktrace library starts review today 14th Dec

Subject: Re: [boost] Stacktrace library starts review today 14th Dec
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-18 13:24:17

On 12/18/16 16:56, Niall Douglas wrote:
> On 18 Dec 2016 at 0:01, Andrey Semashev wrote:
>
>>> * addr2line and forking is not nice. Is linking with a GPL licensed
>>> code an acceptable alternative?
>>
>> I think it would be difficult to get it accepted, but probably
>> possible if it's a separate header, on which nothing from the rest of
>> the library depends. Of course, the most preferable solution is to
>> have the whole library licensed under BSL.
>>
>> Maybe there is a different implementation of the functionality
>> provided by addr2line? Niall mentioned a tool from LLVM, maybe its
>> code can be reused (and I'm assuming it's licensed under BSD).
>
> Unfortunately the LLVM library is extensive and extracting just the
> code you need to do DWARF table lookups is non-trivial. addr2line
> uses a LGPL libdwarf library, again non trivial to extract just what
> you need which is a tiny subset of a DWARF utility library.

LGPL is actually better than GPL. If I'm not mistaken, it is possible to 
make a BSL-licensed backend of Boost.Stacktrace that uses the 
LGPL-licensed libdwarf.

> Many years ago to work around async safety and back when DbgHelp.dll
> had two, totally incompatible versions and each user's system could
> have either, I found a superb COFF and DWARF parsing library written
> by some Russian guy which was malloc-free and async-safe and made
> looking up a source file and line number really easy. I tried finding
> it again for Antony last month, but after 20 minutes I gave up. I
> last used that library maybe a decade ago.
>
> It actually wouldn't be too much work to write your own DWARF parser
> to extract source file and line number. The DWARF spec is well
> documented, and it's basically just five levels of searching tables
> and jumping down to the next layer if memory serves. One could write
> such a parser without too much work, but most of the effort would
> actually go on debugging it. After all, it would need to cope with
> stripped symbols, non-Intel symbols, big endian vs little endian,
> weird symbols generated by bugs in a particular compiler version and
> so on.
>
> https://github.com/aclements/libelfin could chop some time off
> development, or you could just go ahead and embed a copy as a git
> subrepo as it's MIT licence.

If Boost.Stacktrace has its own implementation, that's even better. I 
guess, it's up to Antony to decide if he has time to implement this.

Thanks, Niall.