[lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

[Jeffrey Tan via lldb-dev]

Hi,

O ur company is using Buck(https://buckbuild.com/) to build internal
service. Recently the build team made a change in buck to not merge dwarf
symbols from each object file into final binary so debugger needs to read
source/symbol table from compilation unit itself.
This seems to break the lldb in various aspect:
1. Setting source line breakpoint in library files are not working
2. Callstack did not show the source location well for library frame

I tried latest lldb which this bug still reproduces. Here is the logging
for it:
(lldb) b TaoDataLayer.cpp:50
Target::AddBreakpoint (internal = no) => break_id = 6: file =
'TaoDataLayer.cpp', line = 50, exact_match = 0
*error: Unable to set breakpoint for TaoDataLayer.cpp:50  at file address
0xffffffffffffffff*
Breakpoint 6: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.


My debugging shows the Address::IsValid() returns false for line start
symbol here because it's file address is 0xffffffffffffffff:
https://github.com/llvm-mirror/lldb/blob/ceb5f6cd339a4bcd49666158578f883c1ec96663/source/Breakpoint/BreakpointResolver.cpp#L263

It seems that, after locating the symbol for the line_entry, the code below
did not update sc.line_entry pointing to the original line_entry so it
contains the uninitialized 0xffffffffffffffff value which will fail the
isValid() check later:
https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/source/Symbol/CompileUnit.cpp#L375

I tried to fix this by doing "sc.line_entry = line_entry;" before
both resolve_scope branches. This seems to fix the breakpoint but the
callstack and source locator still can't locate the source file correctly
while hitting the breakpoint.

Questions:
1. Is this a known issue? If so, is there any existing fix I can port?
2. If not, does my investigation above sound reasonable? Any
suggestion/direction for callstack and source locator part of fix?

Thanks
Jeffrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170109/72d7289b/attachment.html>