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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/b7ef0b9f/attachment.html>
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>
On Wed, Nov 5, 2014 at 6:54 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:> 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! >Sorry it took a while ;)> 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.> > -- > Alexey Samsonov > vonosmas at gmail.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/3e533af8/attachment.html>