<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 6:54 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 4, 2014 at 4:32 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So, after many shenanigans, we finally have -gmlt-like inline summary debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/<br><br>Testing this with asan, it seems to be working:<br><br>Given a simple example of inlining failure:<br><div>$ cat asan.cpp</div><div>__attribute__((always_inline)) inline void func(int* i) { *i = 3; }</div><div><br></div><div>int main() {</div><div>  func(nullptr);</div><div>}<br><br>The failures before this change:<br><br><div>    #0 0x4a320e in func(int*) /tmp/dbginfo/asan.cpp:1:59</div><div>    #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4<br><br>And then if we delete the .dwo (to simulate running on another machine, etc, etc):<br><br>    #0 0x4a320e in main /tmp/dbginfo/asan.cpp:1:59<br><br>So we get the expected weird mixed stack frame.<br><br>Then, with the improvements, we see:<br><br><div>    #0 0x4a320e in func /tmp/dbginfo/asan.cpp:1:59</div><div>    #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4<br><br>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.<br><br>Just thought I'd mention it in case that's a thing you'd like to see fixed/worry about.</div></div></div></div></blockquote><div><br></div></div></div><div>Thanks, great to see this coming!</div></div></div></div></blockquote><div><br>Sorry it took a while ;)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That is, the contents of .dwo file is a strict superset of the debug info in executable,<br></div></div></div></div></blockquote><div><br>This is certainly correct (.dwo is a strict superset of .o data)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and we should prefer to fetch function names from DIEs in .dwo to fetching trimmed names from DIEs in executable?</div></div></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think we should fix that (I can work on that once you verify my statement).</div></div></div></div></blockquote><div><br>Cool cool - happy to chat over lunch or something, but sounds like we're on the same page.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</font></span></div></div>
</blockquote></div><br></div></div>