Re: gdb and fission scheme (gcc: -gsplit-dwarf, gnu ld gold :--gdb-index )

["ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>]

I think the following problem is related to the reading of dynamically linked libxul.so library file.
The problem affects the behavior of gdb in that it fails to access the source files.
So it can not list the source lines.

I checked the operation of gdb against statically linked small program and
all is well.
It can list the source files, and this is the first thing I immediately noticed.

With the setup described in the previous post of mine,
gdb can print the stack trace (sans the argument values), but
it can't print source files. Since the argument values are not shown in the
stack trace. Its value is also diminished.

Help is appreciated.
Yes, libxul.so is rather large. Thunderbird is a large program and so
we may hit into an unknown bug here.



(2013/09/20 14:24), ishikawa wrote:
> Hi,
> 
> I recently learned of "-gsplit-dwarf" of GCC 4.8 and -Wl,--gdb-index
> that is passed to GNU ld.gold linker, and have tried to use the split
> debug information scheme for local compilation and link of mozilla
> thunderbird mail client.
> ( http://gcc.gnu.org/wiki/DebugFission )
> 
> The compiling and linking produced working thunderbird binary.  The
> time required for whole build process, especially the time necessary
> for creating a large libxul.so file diminished dramatically.  I would
> like to thank all the developers who have made this possible.
> 
> There is a fly in the ointment, though.  Unfortunately, somehow gdb is
> not reading the symbol information from a created shared library,
> libxul.so, correctly.  Below is the beginning of a gdb session of
> trying to debug a crash of thunderbird: I attach gdb to a dying
> thunderbird process.  Note the error message marked with **** in the
> excerpted lines.
> 
> This bug is discussed in the following bug entry and
> the gdb session log is also uploaded at the following URLs.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=918234
> https://bug918234.bugzilla.mozilla.org/attachment.cgi?id=807287
> 
> 
> Except of gdb session
> 
> 
> $ gdb ../../.././mozilla/dist/bin/thunderbird 29680
> GNU gdb (GDB) 7.6 (Debian 7.6-5)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> 
> *****
> ***** The next line states that such file or directory does not exist
> ***** (in Japanese).
> ***** Strange: the command line is suggested by mozilla's
> ***** |make mozmill| test suite. I have never figured out what
> ***** the relative path is meant to be.
> ***** This may play an important role when -gsplit-dwarf is used.
> ***** Anyway as you can see from the full session log in the above URL,
> ***** libraries and such are correctly accessed and symbols are
> ***** deciphered except for libxul.so and a few others.
> 
> ../../.././mozilla/dist/bin/thunderbird: そのようなファイルやディレクトリは
> ありません.
> Attaching to process 29680
> 
> **** PROBLEM! A fly in the ointment!
> **** Next line indicates that there is some mismatch of the data
> **** layout and gdb's read routine.
> 
> Reading symbols from
> /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/thunderbird...Dwarf Error: CU at
> offset 0x0 references
> unknown DWO with ID 77955146488e868b [in module
> /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/thunderbird]
> (no debugging symbols found)...done.
> 
>      **** I am afraid Debian GNU/Linux does not ship symbol information for
>      **** ld*.so type files: these files seem to be shipped in stripped
>      **** form.
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols
> from
> /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.17.so...done.
> done.
> [New LWP 29712]
> [New LWP 29708]
> [New LWP 29693]
> [New LWP 29692]
> [New LWP 29687]
> [New LWP 29686]
> 
>       ... the rest omitted ...
> 
> 
> I wonder if anyone can shed light on the error:
> Dwarf Error: CU at offset 0x0 references unknown DWO with ID
> 77955146488e868b [in module
> /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/thunderbird]
> (no debugging symbols found)...done.
> 
> I am using
> gcc 4.8
>      gcc-4.8 --version
>      gcc-4.8 (Debian 4.8.1-2) 4.8.1
>      Copyright (C) 2013 Free Software Foundation, Inc.
>      This is free software; see the source for copying conditions.  There is NO
>      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ld.gold
>      ld    --version
>      GNU gold (GNU Binutils for Debian 2.22) 1.11
>      Copyright 2011 Free Software Foundation, Inc.
>      This program is free software; you may redistribute it under the terms of
>      the GNU General Public License version 3 or (at your option) a later
> version.
>      This program has absolutely no warranty.
>      ishikawa@vm-debian-amd64:/COMM-CENTRAL/comm-central$
> 
> gdb
>      gdb --version
>      GNU gdb (GDB) 7.6 (Debian 7.6-5)
>      Copyright (C) 2013 Free Software Foundation, Inc.
>      License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
>      This is free software: you are free to change and redistribute it.
>      There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>      and "show warranty" for details.
>      This GDB was configured as "x86_64-linux-gnu".
>      For bug reporting instructions, please see:
>      <http://www.gnu.org/software/gdb/bugs/>.
> 
> (I have upgraded objcopy, etc. to support the split-dwarf scheme, also.
> Otherwise, the compile and liking with the options mentioned above would fail.)
> 
> If this reading failure on startup of gdb
> is a known error (in which case, I would like it to be fixed
> soon), or if there is a workaround, or if I am using gdb incorrectly,
> I would like to hear about it.
> 
> TIA
> 
>