http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #14 from Alexey Samsonov <samsonov at google dot com> --- (In reply to Kostya Serebryany from comment #13) > > Why don't you use libbacktrace for that? It is not GPL, so Apple and other > > I *think* we evaluated libbacktrace over 2 years ago and > discarded for some technical reason. Or was this something else? > Alexey? > We may want to re-evaluate it, but OTOH llvm-symbolizer works fine for us > already. I don't remember that, probably I should take a closer look at it. On a first glance, we'll still have to spend some effort to make it work fine with sanitizers - e.g. backtrace calls malloc, and likely other library functions. We must also ensure that it's able to unwind inlined frames, and debug info produced by -gline-tables-only/-gmlt. It works for ELF binaries only, while llvm-symbolizer supports Mach-O (and we use it on Mac). > > The symbolizer is pluggable so we may use another one in gcc. > > > > GPL haters can't complain, maintained by Google, and IMHO it is far better > > to just use existing code base for that rather than writing yet another > > DWARF parser. > > *We* are not writing yet another parser, we are reusing the code used by > lldb. Not really, we use a DWARF parser in LLVM, it's a fork of the one used in lldb. I think we'll be able to add support for certain DWARF GNU extensions to make it work with GCC-produced binaries. E.g. llvm-symbolizer already have basic support for DWAARF-5 Fission proposal. > > > Especially if you are writing it as part of llvm, it will unlikely handle > > all the DWARF GNU extensions needed to symbolize GCC code. > > Sure, there is work to be done on libbacktrace to handle some still > > unhandled extensions (e.g. DWZ produced extensions), but if you use > > libbacktrace, that can be done just in one spot, otherwise it will need to > > be written two times.
