[lldb-dev] sharing code between lldb and AddressSanitizer

[Dmitry Vyukov]

Greg Clayton <gclayton <at> apple.com> writes:
> You first need to create a target:
> 
> // Init LLDB
> SBDebugger::Initialize();
> 
...
> 
> So we can do a very good job at symbolicating
> inlined functions within concrete functions,
> all from just a single address.

Hi,

I am with Kostya on it.
I've got to successfully build it on Linux
(the patches are already upstreamed).
Generally it works, thanks for all your work!

I use code similar to the above. The only difference is
that to "unwind" inlining I use:
  SBSymbolContext ctx = ...;
  SBBlock block = ctx.GetBlock();
  for (; block.IsValid(); block = block.GetParent()) {
    if (block.IsInlined())
      printf("  %s %s:%d\n", block.GetInlinedName(),
        block.GetInlinedCallSiteFile().GetFilename(), block.GetInlinedCallSiteLine());
  }
It seems to provide more precise function names.

As for factoring out some code into llvm to share it with ASan.
The code uses SBDebugger/SBTarget/SBModule/
SBSection/SBAddress/SBSymbolContext,
so it seems that it pulls basically whole lldb. I am not sure as 
to whether it's possible to factor out it all
(then lldb will be empty:)).
What do you think?
We can use the dwarf reader that you already factored out.
But it seems a whole lot of work
to build the symbolizer on top of raw dwarf reader, right? So basically
we will have to double a lot of lldb code...

If we decide to depend on lldb, we will appreciate
if you provide a static lldb.a
(along with liblldb.so).

Ironically the symbolizer works great on gcc-compiled binaries,
but fails on clang-compiled binaries.
It provides some info but it's dead wrong (point into some
random STL source files).
objdump -dlS shows 
correct info for the binaries, and I guess you mostly work with
clang-compiled binaries.
So are there any known problems? What may I be missing?
It's all on Linux/amd64.

TIA