Hi Jeffrey, For the source code locating issue based on your info my guess is that LLDB doesn't able to resolve the relative file name path specified in your symbol files to the absolute path required to load the file from disk. Can you try running "target modules dump line-table <file-name>" where the file name is just the name of the file without any path? If the problem is what I am guessing then you should see an output like this (note the relative path). (lldb) target modules dump line-table s.cpp Line table for ./foo/s.cpp in `a.out 0x0000000000400a0d: ./foo/s.cpp:3 0x0000000000400a1a: ./foo/s.cpp:4 0x0000000000400a58: ./foo/s.cpp:4 0x0000000000400a64: ./foo/s.cpp:5 0x0000000000400a93: ./foo/s.cpp:6 0x0000000000400a9e: ./foo/s.cpp:6 ...
The above problem can be worked around either by running LLDB with a current working directory where the file path displayed by "target modules dump line-table" is relative to or setting up a directory remapping for that path using "settings set target.source-map ./ <absolute-path>". Tamas On Mon, Jan 9, 2017 at 11:55 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > In ELF files if there is a section named “.gnu_debuglink” it will contain > a path to the external debug file. Dump this section and see what it > contains. This section contains a null terminated C string as the path > followed by a 4 byte aligned 32 bit integer which is a file CRC. Check to > see the path is relative. > > I am guessing this is your problem. > > Greg > > > On Jan 9, 2017, at 3:42 PM, Jeffrey Tan <jeffrey.fu...@gmail.com> wrote: > > Hey Greg, I just confirmed this with our build team. I seem to have > misunderstood the location of debug symbol. It is actually not inside each > individual object file but: > The debug info in dev mode sits in the .debug_* sections of the shared > libraries (we don't use debug fission). > One potential complicating factor is that we relativize the > DW_AT_comp_dirattributes > in the DWARF info, so that it's almost always just a long reference to the > current working directory (e.g. .///). > > I do not know why this(symbol in shared library) would cause the bug > though. > > Jeffrey > > On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton <clayb...@gmail.com> wrote: > > Comments below. > > On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > 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. > > > How are debug symbols expected to be found? Is fission being used where > the DWARF for each compile unit is in .dwo files and the main executable > has skeleton DWARF? I will skip all other questions until we know more > about how and where the DWARF is. > > Greg Clayton > > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
