[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable

2018-07-18 Thread sourceware at wdtz dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Will Dietz changed: What|Removed |Added CC||sourceware at wdtz dot org -- You are

[Bug ld/23428] ld does not put program headers in a code-only load segment

2018-07-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 H.J. Lu changed: What|Removed |Added Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com

[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable

2018-07-18 Thread bugdal at aerifal dot cx
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx -- You are

[Bug ld/23428] New: ld does not put program headers in a load segment when static linking an executable

2018-07-18 Thread nszabolcs at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Bug ID: 23428 Summary: ld does not put program headers in a load segment when static linking an executable Product: binutils Version: 2.31 Status: UNCONFIRMED

[Bug binutils/23261] objcopy doesn't convert REL to RELA relocations when converting from i386 to x86-64.

2018-07-18 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23261 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com

[Bug binutils/23261] objcopy doesn't convert REL to RELA relocations when converting from i386 to x86-64.

2018-07-18 Thread s at pahtak dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23261 --- Comment #2 from Stephen Checkoway --- (In reply to Alan Modra from comment #1) > I doubt that this feature will ever be implemented. It isn't so easy to > translate relocations from one target to another. I believe the i386 to x86-64

[Bug ld/23428] ld does not put program headers in a load segment when static linking an executable

2018-07-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug ld/23425] New: unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'

2018-07-18 Thread rguenth at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 Bug ID: 23425 Summary: unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract

[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'

2018-07-18 Thread rguenth at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #2 from Richard Biener --- A similar issue seems to happen with .debug_str lookups: /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846). ... later undefined reference

[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'

2018-07-18 Thread rguenth at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #1 from Richard Biener --- Created attachment 11143 --> https://sourceware.org/bugzilla/attachment.cgi?id=11143=edit testcase To reproduce do > ./ld-new -o a.out ccELcIbzdebugobjtem cccLlhS9debugobjtem >

[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'

2018-07-18 Thread jg at jguk dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 Jon Grant changed: What|Removed |Added CC||jg at jguk dot org -- You are receiving

[Bug gas/23418] Incorrect xmmword is accepted

2018-07-18 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23418 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The binutils-2_31-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=01683b308a016c49418aee27241389bd2560e0f1 commit

[Bug gas/23418] Incorrect xmmword is accepted

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

[Bug gas/23418] Incorrect xmmword is accepted

2018-07-18 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23418 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=11a322db5c8bc23009e97af30180d6b14d86dbd3 commit

[Bug ld/23426] New: ld manual is inconsistent with reality w.r.t. default --hash-style value

2018-07-18 Thread vlad at ispras dot ru
https://sourceware.org/bugzilla/show_bug.cgi?id=23426 Bug ID: 23426 Summary: ld manual is inconsistent with reality w.r.t. default --hash-style value Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED

[Bug binutils/23405] Some inputs may cause objcopy to crash, without being detected by error checking or assertions

2018-07-18 Thread zhanggen12 at hotmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23405 --- Comment #4 from zhanggen12 at hotmail dot com --- (In reply to Alan Modra from comment #3) > Yes, I see a segfault with 2.30, but don't with 2.31. I don't believe we > should be spending time fixing bugs that are only tickled by fuzzed

[Bug binutils/23405] Some inputs may cause objcopy to crash, without being detected by error checking or assertions

2018-07-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23405 --- Comment #5 from H.J. Lu --- (In reply to zhanggen12 from comment #4) > (In reply to Alan Modra from comment #3) > > Yes, I see a segfault with 2.30, but don't with 2.31. I don't believe we > > should be spending time fixing bugs that are