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

On 30.06.2026 10:19, Jan Dubiec wrote:
> 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…

Can't the [ishost ...] you present use in the .exp file equally be used
in the .d files:

#xfail: [ishost *-mingw*]

?

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

I see.

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

Is this betting of yours backed by any insight you have? (If we're uncertain,
I think at least the commit message should mention this fact. If later someone
notices the same issue on Cygwin, they'd know right away what to do about it.)

Jan