[Bug ld/25541] linking twice to the same msvc import library produces an invalid IAT

https://sourceware.org/bugzilla/show_bug.cgi?id=25541 Dan Raymond changed: What|Removed |Added CC||martin at martin dot st -- You are rec

[Bug ld/25541] New: linking twice to the same msvc import library produces an invalid IAT

https://sourceware.org/bugzilla/show_bug.cgi?id=25541 Bug ID: 25541 Summary: linking twice to the same msvc import library produces an invalid IAT Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: no

[Bug ld/25540] using the same filename for MAP and DLL fails silently with file corruption

https://sourceware.org/bugzilla/show_bug.cgi?id=25540 Dan Raymond changed: What|Removed |Added CC||martin at martin dot st -- You are rec

[Bug ld/25540] New: using the same filename for MAP and DLL fails silently with file corruption

https://sourceware.org/bugzilla/show_bug.cgi?id=25540 Bug ID: 25540 Summary: using the same filename for MAP and DLL fails silently with file corruption Product: binutils Version: 2.30 Status: UNCONFIRMED Severi

[Bug gas/25539] New: fix-loongson3-llsc cannot produce `sync` when there are multi label at the same address

https://sourceware.org/bugzilla/show_bug.cgi?id=25539 Bug ID: 25539 Summary: fix-loongson3-llsc cannot produce `sync` when there are multi label at the same address Product: binutils Version: 2.35 (HEAD) Status: NEW

Issue 20068 in oss-fuzz: binutils:fuzz_disassemble: Undefined-shift in print_insn

Updates: Labels: -restrict-view-commit Comment #2 on issue 20068 by sheriffbot: binutils:fuzz_disassemble: Undefined-shift in print_insn https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20068#c2 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly

Issue 20039 in oss-fuzz: binutils:fuzz_bfd: Direct-leak in wasm_scan

Updates: Labels: -restrict-view-commit Comment #3 on issue 20039 by sheriffbot: binutils:fuzz_bfd: Direct-leak in wasm_scan https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20039#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -

Issue 20043 in oss-fuzz: binutils:fuzz_bfd: Timeout in fuzz_bfd

Updates: Labels: -restrict-view-commit Comment #3 on issue 20043 by sheriffbot: binutils:fuzz_bfd: Timeout in fuzz_bfd https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20043#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You

[Bug gas/24546] x86-64 far jump/call encoding issues

https://sourceware.org/bugzilla/show_bug.cgi?id=24546 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug gas/24546] x86-64 far jump/call encoding issues

https://sourceware.org/bugzilla/show_bug.cgi?id=24546 --- Comment #10 from Jan Beulich --- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=5990e377e5a339bce715fabfc3e45b24b459a7af I don't see a mechanism in the web interface though how to change a bug's status, so I'm lea

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #42 from H.J. Lu --- (In reply to Martin Liška from comment #39) > > > > What is wrong to use the matching lto-wrapper for the plugin being used? > > It's probably fine. I'm just wondering how to use a locally install GCC to > co

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #40 from Martin Liška --- I will have to start using AR=gcc-ar, ... -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #39 from Martin Liška --- > > What is wrong to use the matching lto-wrapper for the plugin being used? It's probably fine. I'm just wondering how to use a locally install GCC to cooperate fine with binutils. -- You are receivin

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #38 from H.J. Lu --- (In reply to Martin Liška from comment #37) > > > > Which liblto_plugin.so did nm load? Which liblto_plugin.so should nm load? > > It loads the following plugin: > > stat("/usr/bin/../lib64/bfd-plugins", 0x7

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #37 from Martin Liška --- > > Which liblto_plugin.so did nm load? Which liblto_plugin.so should nm load? It loads the following plugin: stat("/usr/bin/../lib64/bfd-plugins", 0x7fffd980) = -1 ENOENT (No such file or directory

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #36 from H.J. Lu --- (

[Bug gas/25531] [Z80][PATCH] Fix SDCC support

https://sourceware.org/bugzilla/show_bug.cgi?id=25531 Sergey Belyashov changed: What|Removed |Added Attachment #12282|0 |1 is obsolete|

[Bug gas/25517] [Z80][PATCH] Use -march=CPU[-EXT][+EXT] instead of lot of options of GAS

https://sourceware.org/bugzilla/show_bug.cgi?id=25517 Sergey Belyashov changed: What|Removed |Added Attachment #12273|0 |1 is obsolete|

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug ld/25537] New: [Z80][PATCH] Move machine type compatibility check from emulation to the BFD

https://sourceware.org/bugzilla/show_bug.cgi?id=25537 Bug ID: 25537 Summary: [Z80][PATCH] Move machine type compatibility check from emulation to the BFD Product: binutils Version: unspecified Status: UNCONFIRMED

[Bug binutils/25355] nm reports data variable as "T" with -flto

https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #34 from Martin Liška --- I have one more question. It's a quite common case for me that that I do testing of the built GCC : $ export PATH=/home/marxin/bin/gcc/bin/:$PATH && export LD_LIBRARY_PATH=/home/marxin/bin/gcc/lib64/:$LD_

RE: Linker --fix-v4bx problem

Hi Gary, It seems to work fine for me. Do you have a reproducer perhaps? > cat test.s .text bx lr > arm-none-linux-gnueabihf-as -march=armv4t test.s -o test.o > arm-none-linux-gnueabihf-ld --fix-v4bx test.o -e0 -o test.exe > arm-none-linux-gnueabihf-objdump -dr test.exe test