On 18 Dec 2016 at 0:01, Andrey Semashev wrote:
I've given it some more thought after I wrote the review, and it occurred to me that the main reason for the current implementation of `basic_stacktrace` as an array is probably the intention to allow its use in signal handlers. For some reason it didn't occur to me while I was writing the review. That is a fair goal, although I'm having a hard time thinking of what can be done with a stacktrace from a signal handler. I guess, the only thing that can be done is dumping it into a file, but the library does not provide such a facility (the `operator<<` is not suitable for this).
In the past I've parsed the backtrace to figure out what call sequence led to the fault causing the signal handler and taken action based on that. In case you're interested, it was a capability based security model where the stacktrace signature was used to cache what capabilities the calling code had. On first time seeing a stacktrace signature, you needed to dig down the stacktrace and figure out what perms it had based on what had called what. You might think thread local data would be a lot easier, but a thread can overwrite its data to fake its security context. Faking a stack backtrace is considerably harder. There are other applications for parsing a backtrace in a signal handler too. They are fairly niche I suppose, but I've used the technique a few times in my career and more than I've ever used virtual inheritance, so it's not a never used technique.
* 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. 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/