<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:12.7272720336914px">adding that setting to .lldbinit appears to fix all three cases (ccache, preprocess and include). </span><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">I want to say "Nice!", except for this part...</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:12.7272720336914px">Because it vastly improves performance for large Objective C and C++ projects when setting file and line breakpoints. See our troubleshooting page for more details:</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">Do you guys have any numbers on what kind of hit this creates?  Doug's analysis seemed to indicate there were links we could follow that might eliminate the need to search everywhere, and perhaps narrow a search for a symbol to just one of a couple places?  So maybe there's some in-between ground here where we don't have to search everywhere for a symbol?</span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">(I'm under the impression from what I read above that if we turn on this option, it means "always search all modules for symbol/breakpoint resolution"?)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 3:41 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because it vastly improves performance for large Objective C and C++ projects when setting file and line breakpoints. See our troubleshooting page for more details:<br>
<br>
<a href="http://lldb.llvm.org/troubleshooting.html" target="_blank">http://lldb.llvm.org/troubleshooting.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Sep 18, 2014, at 3:38 PM, Doug Snyder <<a href="mailto:dsnyder@blueshiftinc.com">dsnyder@blueshiftinc.com</a>> wrote:<br>
><br>
> adding that setting to .lldbinit appears to fix all three cases (ccache, preprocess and include).  this was tested in xcode with individual test cases that i created.<br>
><br>
> i wonder why that setting is not on by default?<br>
><br>
><br>
><br>
><br>
> On Thu, Sep 18, 2014 at 1:42 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> Hey Doug,<br>
><br>
> Can you give Jim's suggestin a try and see if that affects anything?<br>
><br>
> Thanks,<br>
> Todd<br>
><br>
> On Wed, Sep 17, 2014 at 2:39 PM, <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> Are any of these bugs fixed by setting:<br>
><br>
> settings set target.inline-breakpoint-strategy always<br>
><br>
> in your .lldbinit file?<br>
><br>
> Jim<br>
><br>
> > On Sep 17, 2014, at 10:34 AM, Doug Snyder <<a href="mailto:dsnyder@blueshiftinc.com">dsnyder@blueshiftinc.com</a>> wrote:<br>
> ><br>
> > i have been investigating several lldb bugs that seem to be related.<br>
> ><br>
> > bug 19974 describes lldb's inability to set a breakpoint in an included file and bug 20297 describes lldb's inability to set a breakpoint when using ccache.  i have also found a similar case where lldb is unable to set a breakpoint when a separate preprocess step has been used before compiling.<br>
> ><br>
> > note: ccache uses a preprocess step to determine which source files need to be rebuilt so using ccache could be considered the same as using a separate preprocess step.<br>
> ><br>
> > all three cases are similar in that the c/c++ preprocessor is involved and alters the way symbols are added to the object files.<br>
> ><br>
> > the following attached files are write-ups of some of my findings for the different cases<br>
> >     ccache - "lldb and ccache.rtf"<br>
> >     preprocessed files - "lldb and preprocessed files.rtf"<br>
> >     include files - "lldb and include files.rtf"<br>
> ><br>
> > all three cases generate the inability to set breakpoints<br>
> ><br>
> > on the Mac, all three cases create object files with "SOL" symbols for preprocessed or included source files.<br>
> ><br>
> > the following attached file describes the object files created for the preprocessed test case on the Mac:<br>
> >     "preprocessed object files.rtf"<br>
> ><br>
> > on ubuntu, it is not as obvious to spot differences in the object files when examining object files that that lldb is unable to set breakpoints.<br>
> ><br>
> > lldb is unable to set breakpoints on both OSX and ubuntu for all three cases.   gdb is able to set breakpoints on both OSX and ubuntu for all three cases.<br>
> ><br>
> > using XCode, i have tried a couple different ways of stepping through lldb to see why it is having trouble setting breakpoints.<br>
> ><br>
> > From top-down, i have traced setting breakpoints in Breakpoint.cpp down thru BreakpointResolver.cpp.  The intended source file does not seem to be in the list of compute units, but i don't know why.<br>
> ><br>
> > From bottom-up, i have tried to follow how ObjectFileMachO.cpp parses symbols, but i'm not sure that this is the correct place to look.  Also, since this is both a MachO problem and an Elf problem, the problem isn't likely to be here anyway.<br>
> ><br>
> > Does anyone familiar with lldb's architecture have any ideas where in the code i should be looking or have a plan-of-attack to suggest?<br>
> ><br>
> > thanks,<br>
> > doug<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > <lldb and ccache.rtf><lldb and preprocessed files.rtf><preprocessed object files.rtf><lldb and include files.rtf>_______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala |   Software Engineer |     <a href="mailto:tfiala@google.com">tfiala@google.com</a> |     <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>