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

[Tamas Berghammer via lldb-dev]

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 at 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.fudan at 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 <clayborg at gmail.com> wrote:
>
> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170112/07482621/attachment.html>