[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-08-13 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16563 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW CC|

[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-08-13 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=16563 --- Comment #7 from cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch,

[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-08-13 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16563 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gm

objdump segfault

2014-08-13 Thread Claudio Fontana
Hello, I got this when objdumping a windows executable (to kick wine into working...) GNU objdump (Linux/GNU Binutils) 2.22.52.0.2.20120424 $ objdump -x -d swtor.exe ... Program received signal SIGSEGV, Segmentation fault. 0x778222b0 in bfd_getl16 () from /usr/lib64/libbfd-2.22.52.0.2.

[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-08-13 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16563 --- Comment #5 from Alan Modra --- I got that wrong. a.o and b.o appear in the correct order in the output .eh_frame. Apparently it is the elf-eh-frame.c code that sees them in reverse order. -- You are receiving this mail because: You are

[Bug binutils/16893] libopcodes decodes some x86 prefixes incorrectly

2014-08-13 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16893 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug ld/16563] Corrupt .eh-frame section created when linking LTO and non-LTO objects

2014-08-13 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16563 --- Comment #4 from Alan Modra --- There are a couple of things going on here, but the "Invalid CIE pointer" is a readelf bug I'd say. There's nothing prohibiting a FDE to be located before its CIE. The .eh_frame cie_id is a signed relative