[Bug libctf/30836] New: ld.exe stuck while processing ctf symbols on 64bit Windows builds

[torbjorn.svensson at foss dot st.com]

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.