[lldb-dev] Fwd: inability to set breakpoints in lldb
Doug Snyder
dsnyder at blueshiftinc.com
Wed Sep 17 10:34:03 PDT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/eb0c5633/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb and ccache.rtf
Type: application/rtf
Size: 5503 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/eb0c5633/attachment.rtf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb and preprocessed files.rtf
Type: application/rtf
Size: 4713 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/eb0c5633/attachment-0001.rtf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preprocessed object files.rtf
Type: application/rtf
Size: 9463 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/eb0c5633/attachment-0002.rtf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb and include files.rtf
Type: application/rtf
Size: 2178 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/eb0c5633/attachment-0003.rtf>
More information about the lldb-dev
mailing list