[Bug binutils/29142] New: Segmentation fault in ar with empty archive and libdeps specified
https://sourceware.org/bugzilla/show_bug.cgi?id=29142 Bug ID: 29142 Summary: Segmentation fault in ar with empty archive and libdeps specified Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: andrey.vihrov at gmail dot com Target Milestone: --- Running the following command: ar qcl foo bar.a produces a segmentation fault. The value passed to "l" does not matter. Adding at least one archive member after "bar.a" resolves the problem, and so does removing "l foo" without adding any members. Only the combination of the factors results in a segfault. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28006] Linking 32-bit x86 binaries using gold drops the .note.gnu.property section
https://sourceware.org/bugzilla/show_bug.cgi?id=28006 Andrey Vihrov changed: What|Removed |Added CC||andrey.vihrov at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/24996] New: Ternary if operator evaluated incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=24996 Bug ID: 24996 Summary: Ternary if operator evaluated incorrectly Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: andrey.vihrov at gmail dot com CC: ian at airs dot com Target Milestone: --- Consider the following linker script: ASSERT(2 == (3 ? 2 : 1), "Should return 2") ASSERT(1 == (0 ? 2 : 1), "Should return 1") ASSERT(3 != (3 ? 2 : 1), "Should not return 3") When passed to ld.gold, all three assertions fail. ld.bfd is fine. It appears that in gold the ternary if operator always returns the first operand. -- 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/27763] New: x86-64 RIP-relative address with labels wraps around signed 32-bit integer
https://sourceware.org/bugzilla/show_bug.cgi?id=27763 Bug ID: 27763 Summary: x86-64 RIP-relative address with labels wraps around signed 32-bit integer Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: andrey.vihrov at gmail dot com Target Milestone: --- Consider the following source: movq test(%rip), %rax .set test, . + 0xF000 When assembled and then disassembled with "objdump -d", this gives 0:48 8b 05 00 00 00 f0mov-0x1000(%rip),%rax The relative address wraps around and results in a negative displacement. This affects expressions with labels, such as (test + 1) and (test - 0x1E000), but not simply 0xF000, which is correctly rejected with Error: 0xf000 out range of signed 32bit displacement Expressions not smaller than 2^32, such as (test + 0xF000), are also correctly rejected: Error: value of 8053063680 too large for field of 4 bytes at 3 -- You are receiving this mail because: You are on the CC list for the bug.
