[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 reproducing this problem on my x86_64 Fedora based host machine. The log for 834253 does not show the contents of the 'divert triple prefixed names' patch, so I am not sure what it does, but we did have a possibly similar problem with RHEL once where multiple versions of the BFD library could be installed on a system. Running binutils programs would result in seg-faults because the wrong shared BFD library was being loaded. The solution for that particular problem was to ensure that all of the possible versions of the binutils rpm that could be installed on a system would have unique version names for the shared libraries, so that incorrect loads could not happen. If you want us to investigate further however then I think that we need a non-Debian specific way to reproduce the problem. Cheers Nick -- 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 binutils/20499] gprof: segmentation fault on invalid symbol file
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 4ca0333f073cb4d86fe9d4e64c9dfdca5deba1e0 Author: Nick Clifton Date: Mon Aug 22 14:16:26 2016 +0100 Prevent a seg-fault in gprof when parsing a corrupt core file. PR gprof/20499 * corefile.c (core_create_syms_from): Avoid walking off the end of the symbol table. -- 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 binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Tobias, Thanks for reporting this problem. I have checked in a patch which should fix it, but please do let us know if you encounter any more issues. Cheers Nick -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 x86_64 Fedora based > host machine. Looking at the archive that I uploaded, I see with od: 000 ! < a r c h > \n / S Y M 6 4 / 020 1 4 7 1 1 8 5 3 I think the "SYM64" implies that the archive is a 64-bit archive map format (Irix 6). This is likely the cause of the incompatibility between the standard 32-bit archive used on all hppa targets and the Debian binutils-multiarch. Looked at an hppa64-hpux archive it didn't have "SYM64". If this is a Debian configuration issue, please close bug. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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:34 AM, dave.anglin at bell dot net wrote: >> If this is a Debian configuration issue, please close bug. > Maybe "--enable-64-bit-bfd". 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 the multiarch build. I could see 64-bit BFD support might be needed for these. It looks like --enable-64-bit-bfd is implicitly enabled and affects creation of 32-bit archives. Dave -- 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 binutils/20499] gprof: segmentation fault on invalid symbol file
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 first iteration (scanf fails, of course). The current implementation would call strlen() on it anyway, so this might -- in very rare occassions -- lead to another segmentation fault due to going past the malloc boundaries. -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 the multiarch build. That is indeed the case. The change came about because of the patch for PR 14625: https://sourceware.org/bugzilla/show_bug.cgi?id=14625 You could add "--enable-64-bit-archive=no" to the Debian multi-arch command line, and this should fix the gcc build problem. But it does mean that when you are using the multi-arch binutils to access MIPS and s390 archives you may run into a compatibility problem. Alternatively you could configure the non multi-arch Debian binutils with "--enable-64-bit-archive=yes" and then all of your supported targets will be using 64-bit archives and everyone should be happy. Well apart from people who care about disk usage of course. Cheers Nick -- 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 binutils/20499] gprof: segmentation fault on invalid symbol file
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()ed, so the content cannot be guaranteed to be > nul-terminated after first iteration (scanf fails, of course). Actually the sscanf ought to seg-fault, although you are right, it porbably wont. What do you think of this potential patch ? It fixes the sscanf calls so that a maximum buffer width is used. sscanf will ensure that the returned string is NULL terminated, so the strlen should then work. Cheers Nick PS. I think that it would be better to use a #define'd constant for BUFSIZ and a related macro to create the sscanf format string. That way if someone wants to change BUFSIZE in the future they will not have to worry about updating the sscanf format as well. -- 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 binutils/20499] gprof: segmentation fault on invalid symbol file
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
pattern fills address, type, and name in that order. If the input is merely
"x", only "address" is filled, the others are left alone.
And that is why "name" is still just a xmalloc()ed area, and the content, from
a C-perspective, undefined. Calling strlen() in such a situation could
therefore trigger a segmentation fault in very rare situations.
You can see it happening if you add a simple printf("name = %s\n", name);
statement after your PR-check. Or by debugging to that position, but I'm more
of a printf-debug person. :)
--
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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 supported targets will be > using 64-bit archives and everyone should be happy. Well apart from people > who > care about disk usage of course. Probably this is the best alternative if 32-bit archives are still supported by ranlib, etc. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 Helge Deller changed: What|Removed |Added CC||deller at gmx dot de -- 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
ld 2.27: segfault on armv7h on input in 'binary' format
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-empty input file in 'binary' format, but not including it, since reproduced on empty file. The above works fine on i686 (same ld version). Also, no problem with ld.gold. (Current workaround.) This problem appeared after a system update. $ ld --version GNU ld (GNU Binutils) 2.27 $ uname -a Linux bmsyncarm 4.4.8-std-1 #1 SMP Mon Apr 25 17:18:53 UTC 2016 armv7l GNU/Linux ld from binutils 2.27-1 from Arch Linux ARM distro. Build details: https://raw.githubusercontent.com/archlinuxarm/PKGBUILDs/master/core/binutils/PKGBUILD Patch applied: https://raw.githubusercontent.com/archlinuxarm/PKGBUILDs/master/core/binutils/binutils-e9c1bdad.patch Sidenote: Reporting here even though help/info say to report bugs to distro, because apparently they no longer accept issues on their github: https://github.com/archlinuxarm/PKGBUILDs/issues Please let me know if more information is needed. Thank you. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
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 reverted. As far as I can tell, this won't break mips64 or s390x. If any 64-bit target actually needs a 64-bit armap due to archive size exceeding 4G, then you'll get that. Also, note that binutils-2.25 and binutils-2.26 created archives with 32-bit armaps for mips64 and s390x if plugins were enabled. -- 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 ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation
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 eacfca90f1ff457d3a7be9d593040218b6208d2b Author: Alan Modra Date: Tue Aug 23 12:20:59 2016 +0930 R_OR1K_GOTOFF_* relocations PR 20475 * elf32-or1k.c (or1k_elf_relocate_section): Offset from _GLOBAL_OFFSET_TABLE_, not start of .got section. -- 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 ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Alan Modra --- fixed. -- 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
