[lldb-dev] Fwd: inability to set breakpoints in lldb

[Doug Snyder]

actually the strategy i suggested would always be slow if ccache was used
or if someone employed a unity build (large number of .cpp files included
in a single .cpp file in order to reduce link times).  "set breakpoint"
would always return 0 locations until target.inline-breakpoint-strategy was
set.

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140918/78572e7e/attachment.html>