[lldb-dev] sharing code between lldb and AddressSanitizer

[Greg Clayton]

On Feb 27, 2012, at 11:40 PM, Dmitry Vyukov wrote:

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

You need to be careful here as the current block contains the file and line of the location that _called_ (it is the callsite) the current inline block, it isn't the file and line of the inlined function itself.

So when you first lookup the address you need to print:

1 - the file and line for the address that was looked up (the SBLineEntry) with the function name for inlined_block[0]
2 - the callsite info from inlined_block[0] and the function name of inlined_block[1]
3 - the callsite info from inlined_block[1] and the function name of inlined_block[2]

So the file and line are always from the previous inlined block...

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

Probably not. Even though you are only seeing the SBDebugger, SBTarget, SBModule, SBSection, SBAddress, SBSymbolContext, you don't realize that underneath all of this the SBModule can be using one or more ObjectFile, SymbolFile, and SymbolVendor plug-ins. 

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

Yeah, that doesn't seem to be a good way to go about it.

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

That is how we build things on MacOSX, and the Makefiles already produce a bunch of .a files that you should be able to use (like clang and llvm). We do have a target (lldb-platform) that links against a .a file that contains all of the .o files from the core of LLDB that is produced by the MacOSX build and then we enable dead code stripping. You should be able to link against only the .a files that you need for your binary and have things work.

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

Not that we know of. Clang binaries work great on MacOSX and symbolicate just fine. If you have any quick examples where address lookups fail, please send me examples off the list.

> It's all on Linux/amd64.

Send me some binaries that fail along with the address that is being used during the lookup and I will take a look.

Greg Clayton

> 
> TIA
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev