Inline Symbolication with -gsplit-dwarf

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.

  • David

Hi,

Hi,

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!

Sorry it took a while :wink:

That is, the contents of .dwo file is a strict superset of the debug info
in executable,

This is certainly correct (.dwo is a strict superset of .o data)

and we should prefer to fetch function names from DIEs in .dwo to fetching
trimmed names from DIEs in executable?

This I believe is the correct direction - as it seems we gain more fidelity
(function type/parameters etc) from the extra data in the .dwo DIEs.

I think we should fix that (I can work on that once you verify my
statement).

Cool cool - happy to chat over lunch or something, but sounds like we're on
the same page.