<div class="gmail_quote">On Tue, Feb 28, 2012 at 10:25 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> You first need to create a target:<br>
>><br>
>> // Init LLDB<br>
>> SBDebugger::Initialize();<br>
>><br>
> ...<br>
>><br>
>> So we can do a very good job at symbolicating<br>
>> inlined functions within concrete functions,<br>
>> all from just a single address.<br>
><br>
> Hi,<br>
><br>
> I am with Kostya on it.<br>
> I've got to successfully build it on Linux<br>
> (the patches are already upstreamed).<br>
> Generally it works, thanks for all your work!<br>
><br>
> I use code similar to the above. The only difference is<br>
> that to "unwind" inlining I use:<br>
>  SBSymbolContext ctx = ...;<br>
>  SBBlock block = ctx.GetBlock();<br>
>  for (; block.IsValid(); block = block.GetParent()) {<br>
>    if (block.IsInlined())<br>
>      printf("  %s %s:%d\n", block.GetInlinedName(),<br>
>        block.GetInlinedCallSiteFile().GetFilename(), block.GetInlinedCallSiteLine());<br>
>  }<br>
> It seems to provide more precise function names.<br>
<br>
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.<br>
<br>
So when you first lookup the address you need to print:<br>
<br>
1 - the file and line for the address that was looked up (the SBLineEntry) with the function name for inlined_block[0]<br>
2 - the callsite info from inlined_block[0] and the function name of inlined_block[1]<br>
3 - the callsite info from inlined_block[1] and the function name of inlined_block[2]<br>
<br>
So the file and line are always from the previous inlined block...<br></blockquote><div><br></div><div>Thanks! I only saw that if I dump everything it contains all the required info, but I did not figure out the exact laws :)</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> As for factoring out some code into llvm to share it with ASan.<br>
> The code uses SBDebugger/SBTarget/SBModule/<br>
> SBSection/SBAddress/SBSymbolContext,<br>
> so it seems that it pulls basically whole lldb. I am not sure as<br>
> to whether it's possible to factor out it all<br>
> (then lldb will be empty:)).<br>
> What do you think?<br>
<br>
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.<br>

<br>
> We can use the dwarf reader that you already factored out.<br>
> But it seems a whole lot of work<br>
> to build the symbolizer on top of raw dwarf reader, right? So basically<br>
> we will have to double a lot of lldb code...<br>
<br>
Yeah, that doesn't seem to be a good way to go about it.<br>
<br>
><br>
> If we decide to depend on lldb, we will appreciate if you provide a static lldb.a (along with liblldb.so).<br>
<br>
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.<br>
</blockquote><div><br></div><div>Well, yes, we can link separate .a files.</div><div><br></div></div>