[Bug sanitizer/59061] Port leaksanitizer

samsonov at google dot com gcc-bugzilla@gcc.gnu.org
Thu Nov 14 11:08:00 GMT 2013


--- 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.

More information about the Gcc-bugs mailing list