[PATCH v3] ld: Rename a file on Windows fails if target already exists

[Jan Beulich]

On 22.07.2025 14:41, Torbjorn SVENSSON wrote:
> On 2025-07-22 13:52, Jan Beulich wrote:
>> On 22.07.2025 11:30, Torbjörn SVENSSON wrote:
>>> Changes since v2:
>>>
>>> - Fixed regression reported by Linaro CI by reversing the
>>>    order of bfd_close calls.
>>
>> How exactly does the order of bfd_close() calls matter?
> 
> I cannot fully answer this question, but doing it in the reverse order (like I did in v2) causes a segmentation fault.
> For some reason, the segmentation fault did not happen when I ran the GCC testsuite for arm-none-eabi on Windows, but it does happen when I run ld testsuite for x86_64-linux-gnu on Linux.

Interesting.

> Doing it in the v2 order gives me this stacktrace in GDB:
> 
> $ gdb -q --args ./ld-new -z norelro -z nomemory-seal  -L/dev/shm/src/binutils-gdb/ld/testsuite/ld-plugin  -r tmpdir/lto-5a.o tmpdir/lto-5b.o --no-error-execstack -o tmpdir/dump tmpdir/dummy.o
> Reading symbols from ./ld-new...
> (gdb) r
> Starting program: /dev/shm/ld/try2/ld/ld-new -z norelro -z nomemory-seal -L/dev/shm/src/binutils-gdb/ld/testsuite/ld-plugin -r tmpdir/lto-5a.o tmpdir/lto-5b.o --no-error-execstack -o tmpdir/dump tmpdir/dummy.o
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00005555555e7951 in bfd_elf64_write_relocs (abfd=0x555555832b70, sec=0x555555835378, data=0x7fffffffd637) at ./bfd.h:952
> 952       return sec == bfd_abs_section_ptr;

I don't think I can see how this statement could cause SEGV. (Likely a Dwarf
anomaly, whether on the gcc or gdb side.)

> (gdb) bt
> #0  0x00005555555e7951 in bfd_elf64_write_relocs (abfd=0x555555832b70, sec=0x555555835378, data=0x7fffffffd637) at ./bfd.h:952
> #1  0x00005555555cef27 in bfd_map_over_sections (abfd=abfd@entry=0x555555832b70, operation=0x5555555e7760 <bfd_elf64_write_relocs>, user_storage=user_storage@entry=0x7fffffffd637) at /dev/shm/src/binutils-gdb/bfd/section.c:1387
> #2  0x00005555555f435f in _bfd_elf_write_object_contents (abfd=0x555555832b70) at /dev/shm/src/binutils-gdb/bfd/elf.c:7183
> #3  0x00005555555cc45e in bfd_close (abfd=abfd@entry=0x555555832b70) at /dev/shm/src/binutils-gdb/bfd/opncls.c:865
> #4  0x00005555555a31f2 in cmdline_add_object_only_section (size=912, contents=0x55555581fd90 "\177ELF\002\001\001") at /dev/shm/src/binutils-gdb/ld/ldlang.c:10843
> #5  cmdline_emit_object_only_section () at /dev/shm/src/binutils-gdb/ld/ldlang.c:11027

I take it that this was the 2nd of the bfd_close()-s then?

In any event, if the order matters in this function, I think a code comment
should say so. Even if (or should I say "especially when") it's not properly
understood why that is.

Jan