[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-22 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eacfca90f1ff457d3a7be9d593040218b6208d2b commit eacfca90f1ff457d3a7be9d593040

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #16 from Alan Modra --- Ah, mips64 or s390x needed to be added to the target list. I think the part of HJ's patch that forces SYM64 archives due to the mere presence of mips64 or s390x in the --enable-targets list ought to be reve

ld 2.27: segfault on armv7h on input in 'binary' format

2016-08-22 Thread redfish
Hit a segfault in ld on an armv7h board: $ touch foo.dat $ /usr/bin/ld -r -b binary -o /tmp/foo.o foo.dat Segmentation fault (core dumped) (gdb) bt #0 0xb6f2ca94 in ?? () from /usr/lib/libbfd-2.27.so #1 0xb6f66ad0 in bfd_elf_final_link () from /usr/lib/libbfd-2.27.so Also segfaults for a non-e

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread deller at gmx dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 Helge Deller changed: What|Removed |Added CC||deller at gmx dot de -- You are recei

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread dave.anglin at bell dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #15 from dave.anglin at bell dot net --- On 2016-08-22 6:51 AM, nickc at redhat dot com wrote: > Alternatively you could configure the non multi-arch Debian binutils with > "--enable-64-bit-archive=yes" and then all of your supporte

[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

2016-08-22 Thread tobias at stoeckmann dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #5 from Tobias Stoeckmann --- The buffers are secured due to their size (to be honest, I didn't even check that when I did my review... *phew* :) ). The actual issue arises if the parsed line does not match "%s %c %s". This patter

[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

2016-08-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #4 from Nick Clifton --- Created attachment 9468 --> https://sourceware.org/bugzilla/attachment.cgi?id=9468&action=edit Proposed patch In reply to Tobias Stoeckmann from comment #3) Hi Tobias, > The variable "name" is malloc()

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #14 from Nick Clifton --- (In reply to dave.anglin from comment #13) Hi Dave, > Still the question remains as to why a 64-bit was created for > hppa-linux-gnu. There were various > mips64 targets in the --enable-targets list in

[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

2016-08-22 Thread tobias at stoeckmann dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #3 from Tobias Stoeckmann --- It is possible to access uninitialized memory now. Take this symbol file for example: x x x a t a The variable "name" is malloc()ed, so the content cannot be guaranteed to be nul-terminated after fi

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread dave.anglin at bell dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #13 from dave.anglin at bell dot net --- On 2016-08-22 10:54 AM, dave.anglin at bell dot net wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20464 > > --- Comment #12 from dave.anglin at bell dot net --- > On 2016-08-22 10:

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread dave.anglin at bell dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #12 from dave.anglin at bell dot net --- On 2016-08-22 10:34 AM, dave.anglin at bell dot net wrote: > If this is a Debian configuration issue, please close bug. Maybe "--enable-64-bit-bfd". Dave -- You are receiving this mail be

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread dave.anglin at bell dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #11 from dave.anglin at bell dot net --- On 2016-08-22 6:16 AM, nickc at redhat dot com wrote: > It still seems to me that this is a Debian specific problem. Or at least I > have not found any way of reproducing this problem on my

[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

2016-08-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

2016-08-22 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4ca0333f073cb4d86fe9d4e64c9dfdca5deba1e0 commit 4ca0333f073cb4d86fe9d4e64c9

[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized

2016-08-22 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #10 from Nick Clifton --- (In reply to dave.anglin from comment #9) Hi Dave, > Applied fix for 834253 was only a partial fix. It still seems to me that this is a Debian specific problem. Or at least I have not found any way of