[lldb-dev] inability to set breakpoints in lldb

Todd Fiala tfiala at google.com
Wed Sep 24 13:09:57 PDT 2014 

This change went up here, with a couple tweaks to documentation (per Greg
and another minor grammatical fix):

svn commit
Sending        source/Target/Target.cpp
Transmitting file data .
Committed revision 218405.


On Wed, Sep 24, 2014 at 11:08 AM, Todd Fiala <tfiala at google.com> wrote:

> Doug - I'll get this in.
>
> On Wed, Sep 24, 2014 at 11:04 AM, Greg Clayton <gclayton at apple.com> wrote:
>
>> Just replace "eInlineBreakpointsHeaders" with "headers" and you are good
>> to go.
>>
>> > On Sep 24, 2014, at 11:01 AM, Doug Snyder <dsnyder at blueshiftinc.com>
>> wrote:
>> >
>> > i'll fix that and create a new patch
>> >
>> >
>> >
>> > On Wed, Sep 24, 2014 at 10:57 AM, Greg Clayton <gclayton at apple.com>
>> wrote:
>> > The text is wrong in the help text. It should't mention
>> "eInlineBreakpointsHeaders", but it should mention "headers" (the actual
>> text you would type for the settings set command). Other than that, it
>> looks good.
>> >
>> > > On Sep 23, 2014, at 3:22 PM, Todd Fiala <tfiala at google.com> wrote:
>> > >
>> > > 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 <
>> dsnyder at 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 <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>
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Todd Fiala |   Software Engineer |     tfiala at google.com |
>> 650-943-3180
>> > >
>> > > <InlineBreakpointsAlways.patch>
>>
>>
>
>
> --
> Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140924/7f54f642/attachment.html>

More information about the lldb-dev mailing list