On Mon, Nov 18, 2013 at 5:39 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > I've kept the possibility to override the symbolizer by magic symbols > (InternalSymbolizer), and as I have no idea how the llvm buildsystem etc. > works and what is the possibility there to add libbacktrace, this just > requires users to compile with SANITIZE_LIBBACKTRACE defined to signal > that backtrace-supported.h and backtrace.h is available and the > sanitizer_symbolizer_posix_libcdep.cc source then decides based on > backtrace-supported.h etc. whether it is usable.
Just FYI for those who don't know, libbacktrace is under a BSD license so there should be no licensing objection to using it in LLVM. > 1) right now libbacktrace performs dl_iterate_phdr only the first time > backtrace_pcinfo or backtrace_syminfo is called, if there are some > dlopens/dlcloses in between that and another querying of the symbolizer, > it won't notice that. Perhaps it can be done only when we don't > find a symbol and/or have some function that tries to dl_iterare_phdr > again, look at cached st_ino/st_mtime or similar, and for threaded > version likely just keep old records, just add a flag to them that they > should be ignored (or say atomically decrease symbol count to zero > and something similar for debug info). Yes, this is a FIXME in dwarf_fileline in libbacktrace/dwarf.c. > 2) for tsan querying of data symbols, apparently the classes want to see > not just the symbol name and start value, but also size. libbacktrace > has all this info available, just doesn't pass it down to the callback. > I wonder if we'd need to create yet another libbacktrace entrypoint, or > if it would be acceptable to do source code incompatible, ABI (at least > on all sane targets) compatible version of just adding another > uintptr_t symsize argument to backtrace_syminfo_callback. I think it would be fine to change the callback. I doubt that libbacktrace is so widely used that we need to worry about backward compatibility at this stage. In particular I imagine that any users of libbacktrace are simply copying the source code, since there is no installable package. > 3) I wonder if libbacktrace couldn't be updated to use __atomic_* builtins, > then it could avoid the ugliness to emulate atomic loads and stores. I think that would be fine. I can't remember why I didn't use the __atomic builtins. Maybe they weren't quite ready at the time. Ian
