[Bug ld/16121] New: alpha: failed assert at bfd/elf64-alpha.c:3935 when using --no-keep-memory

2013-11-05 Thread mcree at orcon dot net.nz
https://sourceware.org/bugzilla/show_bug.cgi?id=16121

Bug ID: 16121
   Summary: alpha: failed assert at bfd/elf64-alpha.c:3935 when
using --no-keep-memory
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: mcree at orcon dot net.nz
Target: alpha

When linking with --no-keep-memory on Alpha get failed assertion:

gcc   -Wl,--no-keep-memory -o test test.c
collect2: ld terminated with signal 11 [Segmentation fault]
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.23.90.20131017 assertion fail
../../bfd/elf64-alpha.c:3935

(where test.c is text book "Hello World!" program.)

I am hazarding a guess that this may be due to similar reasons as described in
bug 15904, namely that the local variable info.changed_contents in
elf64_alpha_relax_section() is not being updated to TRUE when it should be thus
resulting in the internal_relocs memory being freed (lines 3994ff of
bfd/elf64-alpha.c) when it should not be.  However the alpha code is quite
different to the ia64 code thus I could not see how to rewrite the patch
provided in bug 15904 for alpha.

-- 
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


[Bug gas/16103] Symbol referenced when it should not be in aarch64

2013-11-05 Thread will.newton at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16103

Will Newton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||will.newton at gmail dot com
 Resolution|--- |FIXED

--- Comment #1 from Will Newton  ---

Fixed in commit 8db49cc2de52033990ae5d4d6aacedc8f986e803.

-- 
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


[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:
You are on the CC list for the bug.

___
bug-binutils mailing list
b