[Bug gold/15758] Gold segfault when using -q option

[dwksrc at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15758

dwk <dwksrc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dwksrc at gmail dot com

--- Comment #3 from dwk <dwksrc at gmail dot com> ---
I am encountering a very similar bug when trying to compile Firefox (latest
source tree, Aurora 27+) with --emit-relocs. An in-source-tree autoconf test
case called llvm-pr8927.m4, which is designed to catch LLVM's pr8927 bug
(http://llvm.org/pr8927), is failing because of gold. Here is the test case:

$ cat test.c
struct foobar {
  int x;
};
static const struct foobar* foo() {
  static const struct foobar d = { 0 };
  return &d;
}
static const struct foobar* bar() {
  static const struct foobar d = { 0 };
  return &d;
}
__attribute__((noinline)) int zed(const struct foobar *a,
                                  const struct foobar *b) {
  return a == b;
}
int main() {
  return zed(foo(), bar());
}
$ gcc test.c -c
$ /tmp/binutils/gold/ld-new test.o -q
/tmp/binutils/gold/ld-new: internal error in emit_relocs_scan, at reloc.cc:550
$

I built gold from source (git commit dd0845d, version reports as "GNU gold (GNU
Binutils 2.24.51.20131031) 1.11") to get a stacktrace from the latest version.

$ gdb -q --args /tmp/binutils/gold/ld-new test.o -q
Reading symbols from /tmp/binutils/gold/ld-new...done.
(gdb) b reloc.cc:550
Breakpoint 1 at 0x5d78c3: reloc.cc:550. (4 locations)
(gdb) r
Starting program: /tmp/binutils/gold/ld-new test.o -q

Breakpoint 1, gold::Sized_relobj_file<64, false>::emit_relocs_scan (
    address@hidden, address@hidden, 
    address@hidden, 
    address@hidden "", p=...) at reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) bt
#0  gold::Sized_relobj_file<64, false>::emit_relocs_scan (
    address@hidden, address@hidden, 
    address@hidden, 
    address@hidden "", p=...) at reloc.cc:550
#1  0x00000000005d91fc in gold::Sized_relobj_file<64, false>::do_scan_relocs (
    this=0x9799c0, symtab=0x7fffffff8180, layout=0x7fffffff83e0, rd=0x9706f0)
    at reloc.cc:469
#2  0x00000000005d22e4 in scan_relocs (rd=<optimized out>, 
    layout=<optimized out>, symtab=<optimized out>, this=<optimized out>)
    at object.h:1069
#3  gold::Scan_relocs::run (this=0x97e250) at reloc.cc:188
#4  0x0000000000617aa5 in gold::Workqueue::find_and_run_task (
    address@hidden, address@hidden)
    at workqueue.cc:319
#5  0x0000000000617dca in gold::Workqueue::process (
    address@hidden, address@hidden)
    at workqueue.cc:495
#6  0x0000000000406674 in main (argc=3, argv=0x7fffffffe388) at main.cc:252
(gdb) p rr
$1 = (gold::Relocatable_relocs *) 0x97bff0
(gdb) c
Continuing.

Breakpoint 1, gold::Sized_relobj_file<64, false>::emit_relocs_scan (
    address@hidden, address@hidden, 
    address@hidden, 
    address@hidden "", p=...) at reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) bt
#0  gold::Sized_relobj_file<64, false>::emit_relocs_scan (
    address@hidden, address@hidden, 
    address@hidden, 
    address@hidden "", p=...) at reloc.cc:550
#1  0x00000000005d91fc in gold::Sized_relobj_file<64, false>::do_scan_relocs (
    this=0x9799c0, symtab=0x7fffffff8180, layout=0x7fffffff83e0, rd=0x9706f0)
    at reloc.cc:469
#2  0x00000000005d22e4 in scan_relocs (rd=<optimized out>, 
    layout=<optimized out>, symtab=<optimized out>, this=<optimized out>)
    at object.h:1069
#3  gold::Scan_relocs::run (this=0x97e250) at reloc.cc:188
#4  0x0000000000617aa5 in gold::Workqueue::find_and_run_task (
    address@hidden, address@hidden)
    at workqueue.cc:319
#5  0x0000000000617dca in gold::Workqueue::process (
    address@hidden, address@hidden)
    at workqueue.cc:495
#6  0x0000000000406674 in main (argc=3, argv=0x7fffffffe388) at main.cc:252
(gdb) p rr
$2 = (gold::Relocatable_relocs *) 0x0
(gdb) q

The interesting part is that it reaches line 550 of reloc.cc twice, and the
first time it succeeds. Maybe this will help provide context for why the second
time fails (triggering the assert). Note that this is just a simple test case,
but if I disable the test case then the final linking of some component of
Firefox fails at the end as well.

I hope this additional test case helps in debugging this bug in gold. I am also
unfamiliar with gold's codebase and don't really know how to investigate this
issue. For now, I can use ld (Firefox provides ./configure --disable-gold), but
I would be willing to assist with debugging this further if necessary.

-- 
You are receiving this mail because:
You are on the CC list for the bug.