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 > <mailto:clayb...@gmail.com>> wrote: > Comments below. > >> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev >> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Hi, >> >> O ur company is using Buck(https://buckbuild.com/ <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
