[Bug ld/32264] New: For Windows, `.CRT` section should be merged into `.rdata`
https://sourceware.org/bugzilla/show_bug.cgi?id=32264
Bug ID: 32264
Summary: For Windows,`.CRT` section should be merged into
`.rdata`
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This program
(https://godbolt.org/z/rsoW7vKd8)
```
#include
volatile int value __attribute__((__section__(".CRT"))) = 1;
int
main(void)
{
value = 2;
printf("value = %d\n", value);
}
```
compiles and runs fine with GCC + LD, but crashes with Clang + LLD.
The reason is that, for MSVC the `.CRT` section is special. It gets merged into
`.rdata` before output, which has two effects: One is that there is no such
section in the final executable, and the other is that it becomes read-only.
LLD implements this correctly, but LD doesn't.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/32252] ./configure produces invalid Makefile
https://sourceware.org/bugzilla/show_bug.cgi?id=32252 --- Comment #5 from dilyan.palauzov at aegee dot org --- When I use most recent dash at commit 60eeccd0324a904a5 installed with ./configure && make && make install, then this line in configure echo 'cat >>"\$ac_tmp/subs1.awk" <<\\_ACAWK &&' && puts in config.status cat >>"/subs1.awk" <<\_ACAWK && With bash 4.4.12 the same line produces cat >>"$ac_tmp/subs1.awk" <<\_ACAWK && -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version while usage of function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Naveen Kumar changed: What|Removed |Added CC||kumar.naveen099 at gmail dot com Summary|Performance issues found|Performance issues found |from binutils version |from binutils version |'2.36' version with |'2.36' version while usage |function|of function |'lang_output_section_statem |'lang_output_section_statem |ent_lookup' |ent_lookup' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32260] regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 Sam James changed: What|Removed |Added CC||matz at suse dot de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243
https://sourceware.org/bugzilla/show_bug.cgi?id=31009 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=32260 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32260] regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 Sam James changed: What|Removed |Added CC||sam at gentoo dot org See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31009 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32260] regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 --- Comment #1 from Michael Matz --- Welcome back big testcase :-) > XXX bfdtab->count=1751 table->nbuckets=524288 > XXX bfdtab->count=1752 table->nbuckets=0 So, something between those two wants to reallocate the hash table to have more buckets than can fit into an uint. Like in that other bug report, maybe also print the sizes of sections or the number of presumed entries that it wants to maximally add to get a feel for how much this is overestimating stuff. (E.g. in sec_merge_maybe_resize to print the 'added' param from inside the if condition there; or sec->size in the sole caller of that function) It may be that this is again a too aggressive overestimation. But it may also be real, in which case we really need to audit the code paths that are supposed to handle the cannot-enlarge-hashtable-anymore case (what essentially is supposed to happen is that these overly large input sections simply aren't deduplicated but pasted into the output as is; obviously something goes wrong for that to happen). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/32252] ./configure produces invalid Makefile
https://sourceware.org/bugzilla/show_bug.cgi?id=32252 --- Comment #6 from dilyan.palauzov at aegee dot org --- I asked on the dash-vger-kernel mailing list: https://lore.kernel.org/dash/9f71540061aef0eb970b23ed3ad7e12faf8b7815.ca...@aegee.org/T/#u -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32260] New: regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 Bug ID: 32260 Summary: regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247 Product: binutils Version: 2.43.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jonny.weir at clearpool dot io Target Milestone: --- Hi, Just to note, this may be related to the following bug I raised previously that was fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=31009 To summarize: I am building a large scale C++23 project now using gcc14 in Debian Linux (sid). I have two build environments, one that uses binutils 2.42.90.20240720-2 (Debian package) and another that uses binutils 2.43.1-3, also a Debian package. One build environment is running slightly behind the other, for obvious reasons :-). Aside from the binutils difference, the build environments are identical. I have been successfully building this project using the 2.42 version of binutils, however I believe another regression has been introduced in the 2.43.1 version (possibly all 2.43 versions have this issue). Where I see the failure is as follows using the 2.43.1 version: g++-14 -o main.o -c -std=c++2b -fexceptions -fconcepts -fcoroutines -flto=auto -Wall -g -O3 main.cpp g++-14 -o output -flto=auto -rdynamic -Wl,-rpath=. -Xlinker -Bstatic -lpthread -lrt -lcurl -lssl -lcrypto If I compile using -O2 everything compiles and links correctly, but when -O3 is used, the following output is produced during the linking phase: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247 /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247 /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247 ... etc ... This is repeated thousands of times, as before. As per the suggetions in the previous ticket, I have added some printf logging above line 247 in bfd/merge.c: printf( "XXX bfdtab->count=%u table->nbuckets=%u\n", bfdtab->count, table->nbuckets ); BFD_ASSERT (!NEEDS_RESIZE (bfdtab->count + 1, table->nbuckets)); to try and work out what is happening, but I haven't been able to determine why nbuckets goes to 0. The output from the build is as follows (duplicate lines have been removed): XXX bfdtab->count=0 table->nbuckets=8192 XXX bfdtab->count=1 table->nbuckets=8192 ... XXX bfdtab->count=125 table->nbuckets=8192 XXX bfdtab->count=126 table->nbuckets=32768 XXX bfdtab->count=127 table->nbuckets=32768 ... XXX bfdtab->count=488 table->nbuckets=32768 XXX bfdtab->count=489 table->nbuckets=65536 XXX bfdtab->count=490 table->nbuckets=65536 ... XXX bfdtab->count=778 table->nbuckets=65536 XXX bfdtab->count=779 table->nbuckets=262144 XXX bfdtab->count=780 table->nbuckets=262144 XXX bfdtab->count=781 table->nbuckets=262144 ... XXX bfdtab->count=1406 table->nbuckets=262144 XXX bfdtab->count=1407 table->nbuckets=524288 XXX bfdtab->count=1408 table->nbuckets=524288 ... XXX bfdtab->count=1751 table->nbuckets=524288 XXX bfdtab->count=1752 table->nbuckets=0 XXX bfdtab->count=1753 table->nbuckets=0 XXX bfdtab->count=1754 table->nbuckets=0 XXX bfdtab->count=1771 table->nbuckets=0 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 XXX bfdtab->count=1772 table->nbuckets=0 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 ... XXX bfdtab->count=871457 table->nbuckets=0 XXX bfdtab->count=871458 table->nbuckets=0 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:248 /bin/ld: /tmp/cc0M4ieT.ltrans0.ltrans.o: access beyond end of merged section (20) /bin/ld: /tmp/cc0M4ieT.ltrans0.ltrans.o: access beyond end of merged section (33) /bin/ld: /tmp/cc0M4ieT.ltrans0.ltrans.o: access beyond end of merged section (41) /bin/ld: /tmp/cc0M4ieT.ltrans0.ltrans.o: access beyond end of merged section (48) ... /bin/ld: final link failed collect2: error: ld returned 1 exit status The total number of lines output is around 860,000 (this count excludes my additional debug logging). Note the version change, I have built this locally from source from the binutils-2_43-branch so that I could edit the merge.c file and reproduce this with the logging. Finally, during this linking stage, the memory usage for binutils 2.42 was around 30G for the /bin/ld process. With 2.43.1 the memory usag
[Bug ld/32260] regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 --- Comment #2 from Jonny Weir --- Ha, thanks :-) Some additional logging would appear to indicate that the next estimation is indeed quite aggressive: XXX bfdtab->count=1713 table->nbuckets=524288 XXX bfdtab->count=1714 table->nbuckets=524288 XXX bfdtab->count=1715 table->nbuckets=524288 XXX sec->size=9282 XXX added=4642 XXX bfdtab->count=1716 table->nbuckets=524288 XXX bfdtab->count=1717 table->nbuckets=524288 XXX bfdtab->count=1718 table->nbuckets=524288 XXX bfdtab->count=1719 table->nbuckets=524288 XXX bfdtab->count=1720 table->nbuckets=524288 XXX bfdtab->count=1721 table->nbuckets=524288 XXX sec->size=13586 XXX added=6794 XXX bfdtab->count=1722 table->nbuckets=524288 XXX bfdtab->count=1723 table->nbuckets=524288 ... XXX bfdtab->count=1750 table->nbuckets=524288 XXX bfdtab->count=1751 table->nbuckets=524288 XXX sec->size=2872400096 XXX added=1436200049 XXX bfdtab->count=1752 table->nbuckets=0 XXX bfdtab->count=1753 table->nbuckets=0 XXX bfdtab->count=1754 table->nbuckets=0 ... /bin/ld: BFD (GNU Binutils) 2.43.1.20241010 assertion fail merge.c:249 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32260] regression: /bin/ld: BFD (GNU Binutils for Debian) 2.43.1 assertion fail ../../bfd/merge.c:247
https://sourceware.org/bugzilla/show_bug.cgi?id=32260 --- Comment #3 from Alan Modra --- Looks to me that merge.c:177 should be unsigned int newnb ... By calculating newnb as unsigned long we get to a count of 2^32 and overflow table->nbuckets without triggering an error in sec_merge_maybe_resize -- You are receiving this mail because: You are on the CC list for the bug.
