[Bug binutils/23282] New: "Tidy bfdio to consistenly use containing archive" patch makes strip.exe on Windows crawl

Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kyrab at mail dot ru Target Milestone: --- 5c4ce239a3ab9263163a0fe8e7487b39a41c43d1 commit leads to strip.exe on mingw-w64 (both

[Bug ld/21471] New: ld rejects pe-bigobj-x86-64 target but shouldn't

y: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: kyrab at mail dot ru Target Milestone: --- Created attachment 10040 --> https://sourceware.org/bugzilla/attachment.cgi?id=10040&action=edit enable pe-bigobj-x86-64 target `ld` spits &quo

[Bug ld/21274] ld segfaults linking PE DLL

https://sourceware.org/bugzilla/show_bug.cgi?id=21274 --- Comment #5 from awson --- Thanks for the patch, but I afraid I won't be able to test it in the near future. (I had understood your first comment correctly, but after some thinking I've decided that staying with fixed-sized buffer is bette

[Bug ld/21274] ld segfaults linking PE DLL

https://sourceware.org/bugzilla/show_bug.cgi?id=21274 awson changed: What|Removed |Added Attachment #9907|0 |1 is obsolete|

[Bug ld/21274] ld segfaults linking PE DLL

https://sourceware.org/bugzilla/show_bug.cgi?id=21274 --- Comment #1 from awson --- Better wording: `pe_create_import_fixup` uses fixed-sized buffer to create decorated names, but this buffer is too small (300 bytes) and is easily overflowed by long mangled names. -- You are receiving this mai

[Bug ld/21274] New: ld segfaults linking PE DLL

Assignee: unassigned at sourceware dot org Reporter: kyrab at mail dot ru Target Milestone: --- Created attachment 9907 --> https://sourceware.org/bugzilla/attachment.cgi?id=9907&action=edit patch `ld` segfaults when linking C++ PE DLL. The culprit is pretty much

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 --- Comment #8 from awson --- And yes, I'm quite happy with the patches. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.o

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 --- Comment #7 from awson --- Sorry, my miswording. In `ELF` case we have *no* any '$'-separated sections. What I meant was that (almost)counterpart of PECOFF dollar-separated sections is ELF dot-separated sections, but while PECOFF dollar-se

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 --- Comment #5 from awson --- I looked further into it. Sections with '$' separator also not only should be merged into the prefix section, but also should be sorted according to their suffix names. I'm not sure if we need this for GHC-generat

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 --- Comment #4 from awson --- Good catch of ".data$*" thing, indeed `gcc` on Windows generates `$` instead of `.`, and this, perhaps, would be correct to make GHC do the same thing, but we already have separate handling of `.text.*` sections o

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 --- Comment #2 from awson --- Created attachment 9684 --> https://sourceware.org/bugzilla/attachment.cgi?id=9684&action=edit Section merging for GHC This patch solves the problem for me. It adds sections merging for the sections generated b

[Bug ld/19254] "too many sections" when linking COFF executables

https://sourceware.org/bugzilla/show_bug.cgi?id=19254 awson changed: What|Removed |Added CC||kyrab at mail dot ru --- Comment #1 from

[Bug ld/17955] Wrong address difference on 64-bit Windows

https://sourceware.org/bugzilla/show_bug.cgi?id=17955 awson changed: What|Removed |Added CC||kyrab at mail dot ru --- Comment #1 from

[Bug ld/19531] ld fails to build proper executables in several cases on x64_64-w64-mingw32

https://sourceware.org/bugzilla/show_bug.cgi?id=19531 --- Comment #3 from awson --- Did you try to inspect the executable linked with 2.16 to understand how many sections it contains? Perhaps, existing linker script doesn't merge some kind(s) of sections correctly? Also, current ld script is bug

[Bug ld/19531] ld fails to build proper executables in several cases on x64_64-w64-mingw32

https://sourceware.org/bugzilla/show_bug.cgi?id=19531 awson changed: What|Removed |Added CC||kyrab at mail dot ru --- Comment #2 from

[Bug binutils/19440] COFF handling bug. In particular, renders bigobj support broken.

https://sourceware.org/bugzilla/show_bug.cgi?id=19440 --- Comment #2 from awson --- Hmm, I've looked into BFD code and have seen several 'in->n_scnum = H_GET_16 (abfd, ext->e_scnum);' and 'H_PUT_16 (abfd, in->n_scnum, ext->e_scnum);' constructs here and there (for example in coffswap.h), where

[Bug binutils/19440] New: COFF handling bug. In particular, renders bigobj support broken.

: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kyrab at mail dot ru Target Milestone: --- Created attachment 8895 --> https://sourceware.org/bugzilla/attachment.cgi?id=8895&action=edit COFF fix Ther