[lldb-dev] sharing code between lldb and AddressSanitizer

[Dmitry Vyukov]

On Tue, Feb 28, 2012 at 10:25 PM, Greg Clayton <gclayton at apple.com> wrote:

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

Thanks! I only saw that if I dump everything it contains all the required
info, but I did not figure out the exact laws :)



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

Well, yes, we can link separate .a files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120229/080a2cc7/attachment.html>