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

2013-11-05 Thread dwksrc at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15758

dwk  changed:

   What|Removed |Added

 CC||dwksrc at gmail dot com

--- Comment #3 from dwk  ---
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 (
this=this@entry=0x9799c0, symtab=symtab@entry=0x7fff8180, 
layout=layout@entry=0x7fff83e0, 
plocal_syms=plocal_syms@entry=0x77ff7508 "", p=...) at reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) bt
#0  gold::Sized_relobj_file<64, false>::emit_relocs_scan (
this=this@entry=0x9799c0, symtab=symtab@entry=0x7fff8180, 
layout=layout@entry=0x7fff83e0, 
plocal_syms=plocal_syms@entry=0x77ff7508 "", p=...) at reloc.cc:550
#1  0x005d91fc in gold::Sized_relobj_file<64, false>::do_scan_relocs (
this=0x9799c0, symtab=0x7fff8180, layout=0x7fff83e0, rd=0x9706f0)
at reloc.cc:469
#2  0x005d22e4 in scan_relocs (rd=, 
layout=, symtab=, this=)
at object.h:1069
#3  gold::Scan_relocs::run (this=0x97e250) at reloc.cc:188
#4  0x00617aa5 in gold::Workqueue::find_and_run_task (
this=this@entry=0x7fff7e30, thread_number=thread_number@entry=0)
at workqueue.cc:319
#5  0x00617dca in gold::Workqueue::process (
this=this@entry=0x7fff7e30, thread_number=thread_number@entry=0)
at workqueue.cc:495
#6  0x00406674 in main (argc=3, argv=0x7fffe388) 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 (
this=this@entry=0x9799c0, symtab=symtab@entry=0x7fff8180, 
layout=layout@entry=0x7fff83e0, 
plocal_syms=plocal_syms@entry=0x77ff7508 "", p=...) at reloc.cc:550
550   gold_assert(rr != NULL);
(gdb) bt
#0  gold::Sized_relobj_file<64, false>::emit_relocs_scan (
this=this@entry=0x9799c0, symtab=symtab@entry=0x7fff8180, 
layout=layout@entry=0x7fff83e0, 
plocal_syms=plocal_syms@entry=0x77ff7508 "", p=...) at reloc.cc:550
#1  0x005d91fc in gold::Sized_relobj_file<64, false>::do_scan_relocs (
this=0x9799c0, symtab=0x7fff8180, layout=0x7fff83e0, rd=0x9706f0)
at reloc.cc:469
#2  0x005d22e4 in scan_relocs (rd=, 
layout=, symtab=, this=)
at object.h:1069
#3  gold::Scan_relocs::run (this=0x97e250) at reloc.cc:188
#4  0x00617aa5 in gold::Workqueue::find_and_run_task (
this=this@entry=0x7fff7e30, thread_number=thread_number@entry=0)
at workqueue.cc:319
#5  0x00617dca in gold::Workqueue::process (
this=this@entry=0x7fff7e30, thread_number=thread_number@entry=0)
at workqueue.cc:495
#6  0x00406674 in main (argc=3, argv=0x7fffe388) 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:
Y

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

2013-11-10 Thread dwksrc at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=15758

--- Comment #7 from dwk  ---
The fix works for me too, thanks Cary!

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils