<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler and David,<br>
<br>
unfortunately it looks more like case 1. This optimization breaks several assumptions that tools in our software stack depend on.<br></blockquote><div><br></div><div>It's a fairly substantial debug info size savings that seems worth investigating whether you can keep it enabled at least in </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- For example, it breaks dtrace, which on Darwin relies on being able to pull the (complete) CTF info (compact C type format) out of the DWARF in the .dSYM for a given module.<br></blockquote><div><br></div><div>I take it you're already using -fno-limit-debug-info for these scenarios, then? (are you using -flimit-debug-info at all?)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Kernel extensions tend to inherit from base classes that are defined in a system framework (I/O Kit works this way for example).<br></blockquote><div><br></div><div>And the library where the base class is defined isn't built with debug info as a matter of course? Is that solvable at all?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- For LLDB it is not always possible to tell where a type came from and vtable symbols can get stripped from the symbol table.</blockquote><div><br>I don't understand the relevance of vtable stripping to this issue - could you explain it to me? (are you suggesting that the vtable symbol lookup could/would be used to locate the right object file/dsym to load the full definition of the type? I'm only vaguely familiar with such an idea and didn't realize you could get from the symbol back to the object file and thus to the dsym).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If it can’t layout the type, the expression evaluator doesn’t work.<br>
<br>
We do need to have the option to turn this optimization off; preferably we would make off the default for Darwin. Other platforms that use LLDB as their primary debugger may want to do the same thing.</blockquote><div><br>
Is there no way to fix LLDB so it actually loads in the other dsyms and finds the full definition of the type? It would seem unfortunate to have such a bloated debug info format (not only for this optimization, but for the existing -flimit-debug-info optimizations and anything else we might think of in the future where we can ensure that some debug info is already availabel in another file).<br>
<br>- David </div></div></div></div>