https://sourceware.org/bugzilla/show_bug.cgi?id=30836
Bug ID: 30836 Summary: ld.exe stuck while processing ctf symbols on 64bit Windows builds Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: torbjorn.svensson at foss dot st.com Target Milestone: --- Created attachment 15104 --> https://sourceware.org/bugzilla/attachment.cgi?id=15104&action=edit pr41893-1.o When running the GCC12 test suite for arm-none-eabi, I discovered that the processing in libctf jumps between 0 and INT_MAX when finding the "offset" in the function "ctf_dedup_rhash_type". INT_MAX comes from that the function ctf_member_next is supposed to return negative value on error, but the function ctf_set_errno is defined to return an unsigned long and ctf_member_next is returning ssize_t that has a wider type on 64bit Windows ABI (extending 32bit unsigned to signed 64bit is not doing the expected here). To reproduce the issue, use the attached object files (created using the pr41893-1.c and pr41893-2.c files from the GCC12 source tree), by running: .../ld.exe -o foo.exe pr41893-1.o pr41893-2.o Be sure that ld.exe is built using x86_64-w64-mingw32 triplet in order to trigger the issue. -- You are receiving this mail because: You are on the CC list for the bug.