[PATCH] ld: Skip p33265-2 and pr33265-2 tests on Windows

[Jan Dubiec]

On 29.06.2026 09:54, Jan Beulich wrote:
> On 29.06.2026 09:27, Jan Dubiec wrote:
>> These tests are expected to fail on Windows because by default maximum path length
>> is only 260 characters:
>> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
>>
>> Theoretically the issue could be fixed in two ways, as pointed in the linked article:
>>     1. using the "\\?\" prefix, but this probably requires a lot of work
>>     and should be done "binutils-wide", i.e. all tools should be reviewed
>>     from this point of view,
>>     2. using manifest file, but this still would require an action from
>>     the user – they would have to turn on long paths support in the
>>     Windows registry.
> 
> Based on this, imo the two tests should become XFAILs instead of being excluded
> altogether. However, ...

I agree, but I wanted the patch be "in spirit of" pr24576-1 and 
pr24576-2 related patch which was posted here in February. Also 
binutils' test framework does not offer an elegant way to xfail a test 
depending on *host*. At least I don't know such a way…

> 
>> Excerpt from the log:
>> [...]
>> PASS: ld-scripts/pr33265-1
>> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
>> Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
>> spawn [open ...]
>> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o
>> Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
>> spawn [open ...]
>> D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory
> 
> ... where are these absurd paths coming from? If there wasn't this excessive
> referencing of the current directory, not problem would arise in the first
> place, as it looks.

 From ld/testsuite/ld-scripts/libpr33265-2.a which recursively includes 
itself:
GROUP ( ./././././/libpr33265-2.a )

The recursion depth is set to 100 (MAX_NESTED_GROUP_DEPTH in ldlang.c) 
and that's why the path is so weird. On Linux the tests pass because 
max. path length is ~4KiB there, on Windows they fail because default 
max. path length is ~16x smaller.

The tests pass on Windows when one sets MAX_NESTED_GROUP_DEPTH to a 
small value, e.g. 20.

> 
>> --- a/ld/testsuite/ld-scripts/script.exp
>> +++ b/ld/testsuite/ld-scripts/script.exp
>> @@ -246,7 +246,11 @@ run_dump_test "segment-start" {{name (overridden)} \
>>   			       {ld -Ttext-segment=0x10000000}}
>>   
>>   run_dump_test "pr33265-1"
>> -run_dump_test "pr33265-2"
>> -run_dump_test "pr33265-3"
>> +# On Windows hosts the following two cases are expected to fail because
>> +# by default maximum path length is only 260 characters.
>> +if { ![ishost *-mingw*] } {
>> +    run_dump_test "pr33265-2"
>> +    run_dump_test "pr33265-3"
>> +}
> 
> What about Cygwin? Does this somehow circumvent the issue?

I have no idea. But I bet that there is no such problem.

> 
> Jan

Jan D.