[LLVMdev] Inline Symbolication with -gsplit-dwarf

[Alexey Samsonov]

Hi,

On Tue, Nov 4, 2014 at 4:32 PM, David Blaikie <dblaikie at gmail.com> wrote:

> So, after many shenanigans, we finally have -gmlt-like inline summary
> debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/
>
> Testing this with asan, it seems to be working:
>
> Given a simple example of inlining failure:
> $ cat asan.cpp
> __attribute__((always_inline)) inline void func(int* i) { *i = 3; }
>
> int main() {
>   func(nullptr);
> }
>
> The failures before this change:
>
>     #0 0x4a320e in func(int*) /tmp/dbginfo/asan.cpp:1:59
>     #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4
>
> And then if we delete the .dwo (to simulate running on another machine,
> etc, etc):
>
>     #0 0x4a320e in main /tmp/dbginfo/asan.cpp:1:59
>
> So we get the expected weird mixed stack frame.
>
> Then, with the improvements, we see:
>
>     #0 0x4a320e in func /tmp/dbginfo/asan.cpp:1:59
>     #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4
>
> One minor quality issue: If we leave the .dwo file in, we still get this
> last output (the symbolizer is favoring the data in the .o file, by the
> looks of it, rather than the .dwo file) rather than the extra detail of the
> function's parameter types, etc.
>
> Just thought I'd mention it in case that's a thing you'd like to see
> fixed/worry about.
>

Thanks, great to see this coming!

That is, the contents of .dwo file is a strict superset of the debug info
in executable, and we should prefer to fetch function names from DIEs in
.dwo to fetching trimmed names from DIEs in executable?
I think we should fix that (I can work on that once you verify my
statement).

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/d1ae18af/attachment.html>