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

[Torbjorn SVENSSON]

On 2025-07-22 14:56, Jan Beulich wrote:
> 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.

Indeed. If someone can shed some light on this, I would very much like to understand why it's like it this. :)

>> 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?

Yes, it's when the obfd is closed that causes the segmentation fault.

> 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.

Fixed in v4.

Kind regards,
Torbjörn

> 
> Jan