I think the patch might be missing from that mail. Here it is though:
On Tue, Sep 23, 2014 at 3:20 PM, Doug Snyder <dsny...@blueshiftinc.com> wrote: > here is a patch that sets the default to eInlineBreakpointsAlways. it > also changes the associated comment text, since the old text > was eInlineBreakpointsHeaders-default-centric > > i manually tested it with lldb using one of my test cases and ran > check-lldb on ubuntu to make sure it wasn't breaking other things > > > On Tue, Sep 23, 2014 at 12:52 PM, Greg Clayton <gclay...@apple.com> wrote: > >> I would vote to switch over to using "always" as the default setting and >> then let people who run into performance problems set it to "headers" >> >> I am not fond of the two state approach because you might be trying to >> set a breakpoint a shared library that isn't loaded yet. >> >> More comments below: >> >> > On Sep 23, 2014, at 12:21 PM, Doug Snyder <dsny...@blueshiftinc.com> >> wrote: >> > >> > it appears that there are a number of possible options for addressing >> lldb's inability to set breakpoints when using ccache, with preprocess >> files and with include files >> > 1) continue using "settings set target.inline-breakpoint-strategy >> always" to get around the problem. however, many/most users aren't aware >> of this setting and aren't aware that they can get around the problem. >> also, the name doesn't imply that this setting will fix the problem for >> ccache or for preprocessed files >> >> We should just make it the default. I don't like that we miss breakpoints >> for no good reason and rely upon an obscure setting to fix this. >> >> > 2) improve the search speed so it's feasible to search all include >> files when working with large projects. this could eliminate the need for >> "settings set target.inline-breakpoint-strategy always". i don't know how >> involved this effort would be. >> >> Search speed isn't the problem, it is the number of files that get >> touched on disk. There probably won't be any performance issues on other >> systems until fission becomes real, but at Apple we leave the debug info in >> the .o files and when debugging large projects we end up having to open >> thousands of .o files. Is is the file cache getting warmed up that causes >> the performance problems. >> >> > 3) add a two-stage file search if the "set breakpoint" initially >> finds 0 locations. i have included a possible patch for this with a >> description below >> >> I don't like this because if you have a shared library that isn't loaded >> yet, you will get no matches, then try again with inlines. It also doesn't >> help catch actual inlined locations in the case where you might have an >> inlined function and an actual concrete instance when the inlining depth >> gets exceeded. >> >> > 4) add .c/.cpp/.m include files to the list of files to search. >> (don't add .h files). this would fix the problem with ccache and >> preprocessed files. this would also make unit builds work. "settings set >> target.inline-breakpoint-strategy always" would still be needed for inline >> routines in .h files. i don't know how well this fits in with the current >> system of searching modules and compile_units. >> > 5) allow different platforms to select how they wish to handle >> this. the best strategy for xcode may be different than the best strategy >> for android. >> > 6) some combination of options above >> >> >> I just suggest changing the default to "always" and we can have people >> that have performance problems change their setting to get the performance >> back. >> >> Greg >> >> > >> > >> > >> > two-stage file search >> > ------------------------------- >> > attached is a patch (target.cpp.diff) that will add include files to >> the search list if a "set breakpoint" has initially found 0 locations and >> check_inlines was false. the second search basically mimics using >> "settings set target.inline-breakpoint-strategy always". >> > >> > this seems to enable setting breakpoints with ccache, preprocessed >> files and include files without having to set >> "target.inline-breakpoint-strategy always" >> > >> > known issues with this patch: >> > 1) in very large projects, if the "set breakpoint" has 0 locations >> in the non-include files, it may take a long time to find (or not find) the >> breakpoint in the include files >> > 2) there is a somewhat clunky breakpoint ID system in the >> breakpoint list. i was able to eliminate a non-sequential ID on a search >> retry, but the next "set breakpoint" will have a non-sequential ID. there >> probably is a way to fix this, but i didn't see it. >> > >> > >> > >> > breakpoint unit tests >> > ---------------------------- >> > attached are two new unit tests (include.zip and preprocess.zip) i >> created to test whether breakpoints can be set in include files and >> preprocessed files >> > >> > i used these unit tests to verify that the two-stage file search patch >> allows setting breakpoints without "settings set >> target.inline-breakpoint-strategy always" >> > >> > i normally place these folders in lldb/test/functionalities/breakpoint >> > >> > >> > >> > doug >> > >> > >> > >> > >> > >> > On Thu, Sep 18, 2014 at 3:52 PM, Doug Snyder <dsny...@blueshiftinc.com> >> wrote: >> > what if the logic was changed to do what it does now, but if the "set >> breakpoint" returns 0 locations, then try again with >> target.inline-breakpoint-strategy set? >> > >> > >> > >> > >> > On Thu, Sep 18, 2014 at 3:41 PM, Greg Clayton <gclay...@apple.com> >> wrote: >> > 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: >> > >> > http://lldb.llvm.org/troubleshooting.html >> > >> > >> > > On Sep 18, 2014, at 3:38 PM, Doug Snyder <dsny...@blueshiftinc.com> >> wrote: >> > > >> > > 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. >> > > >> > > i wonder why that setting is not on by default? >> > > >> > > >> > > >> > > >> > > On Thu, Sep 18, 2014 at 1:42 PM, Todd Fiala <tfi...@google.com> >> wrote: >> > > Hey Doug, >> > > >> > > Can you give Jim's suggestin a try and see if that affects anything? >> > > >> > > Thanks, >> > > Todd >> > > >> > > On Wed, Sep 17, 2014 at 2:39 PM, <jing...@apple.com> wrote: >> > > Are any of these bugs fixed by setting: >> > > >> > > settings set target.inline-breakpoint-strategy always >> > > >> > > in your .lldbinit file? >> > > >> > > Jim >> > > >> > > > On Sep 17, 2014, at 10:34 AM, Doug Snyder <dsny...@blueshiftinc.com> >> wrote: >> > > > >> > > > i have been investigating several lldb bugs that seem to be related. >> > > > >> > > > 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. >> > > > >> > > > 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. >> > > > >> > > > all three cases are similar in that the c/c++ preprocessor is >> involved and alters the way symbols are added to the object files. >> > > > >> > > > the following attached files are write-ups of some of my findings >> for the different cases >> > > > ccache - "lldb and ccache.rtf" >> > > > preprocessed files - "lldb and preprocessed files.rtf" >> > > > include files - "lldb and include files.rtf" >> > > > >> > > > all three cases generate the inability to set breakpoints >> > > > >> > > > on the Mac, all three cases create object files with "SOL" symbols >> for preprocessed or included source files. >> > > > >> > > > the following attached file describes the object files created for >> the preprocessed test case on the Mac: >> > > > "preprocessed object files.rtf" >> > > > >> > > > 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. >> > > > >> > > > 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. >> > > > >> > > > using XCode, i have tried a couple different ways of stepping >> through lldb to see why it is having trouble setting breakpoints. >> > > > >> > > > 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. >> > > > >> > > > 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. >> > > > >> > > > 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? >> > > > >> > > > thanks, >> > > > doug >> > > > >> > > > >> > > > >> > > > >> > > > <lldb and ccache.rtf><lldb and preprocessed files.rtf><preprocessed >> object files.rtf><lldb and include >> files.rtf>_______________________________________________ >> > > > lldb-dev mailing list >> > > > lldb-dev@cs.uiuc.edu >> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > > >> > > _______________________________________________ >> > > lldb-dev mailing list >> > > lldb-dev@cs.uiuc.edu >> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > > >> > > >> > > >> > > -- >> > > Todd Fiala | Software Engineer | tfi...@google.com | >> 650-943-3180 >> > > >> > > >> > > _______________________________________________ >> > > lldb-dev mailing list >> > > lldb-dev@cs.uiuc.edu >> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > >> > >> > >> > <target.cpp.diff><include.zip><preprocess.zip> >> >> > -- Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180
InlineBreakpointsAlways.patch
Description: Binary data
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
