[lldb-dev] inability to set breakpoints in lldb

Tue Sep 23 15:20:16 PDT 2014

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 <gclayton at 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 <dsnyder at 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 <dsnyder at 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 <gclayton at 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 <dsnyder at 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 <tfiala at 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, <jingham at 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 <dsnyder at 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 at cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > >
> > >
> > >
> > > --
> > > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> > >
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> > <target.cpp.diff><include.zip><preprocess.zip>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140923/a9ef0353/attachment.html>