On Mon, Nov 18, 2013 at 07:49:03PM +0400, Alexey Samsonov wrote:
> > As for sanitizer, the reason I haven't implemented SendCommand method for
> > the libbacktrace symbolizer is that the library doesn't provide the info
> > as text, but as individual values passed to the callback, so printing
> > that to text and then parsing the text would be very ugly. libbacktrace
> > doesn't even need the module names and module offsets,
>
>
> If libbacktrace does its own call of dl_iterate_phdr, then it doesn't need
> many
It does.
> pieces of existing Symbolizer (or POSIXSymbolizer, in new version of source
> code)
> complexity - like FindModuleForAddress() function. Consider creating a
> separate
Well, as fallback it still needs that. libbacktrace APIs won't tell you:
"ok, see, I don't know exactly what this symbol is, but it is in DSO
libfoobar.so plus offset 0x123456". It tells you either
function name and file/line (for backtrace_pcinfo callback, possibly several
times to iterate through inline frames) or symbol name and symbol value
(hopefully in the future also symbol size) for backtrace_syminfo callback.
If the address isn't found in debug info resp. symbol tables, you just get
NULL function name of symbol value, NULL filename and 0 line number or
symbol value. Initially I had the code as a different toplevel symbolizer,
but for the case where libbacktrace isn't there, or where it isn't usable
(due to host limitations e.g. not thread safe, or using malloc, etc.)
there needs to be a fallback to the POSIXSymbolizer.
Jakub
