https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115698
--- Comment #3 from Yihan Dang <yhdang at stu dot xjtu.edu.cn> ---
Hello Andrew, thank you very much for your reply! I think I've found the catch:
Change the custom ld script to this:
```
#!/bin/bash
echo "hello from custom ld, arguments are: $*"
filename=$1
filename=${filename:1}
if [ -e "$filename" ]; then
cat "$filename"
fi
exit 0
```
The one that does NOT use `@file` syntax would print out all arguments right
here:
```
hello from custom ld, arguments are: -plugin
/usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper ...
```
But the one that DOES use it would output something like:
```
hello from custom ld, arguments are: @/tmp/ccMXQbBc
# /tmp/ccMXQbBC contains all arguments as above
```
Since `ld.libhugetlbfs` does not extract argument from `@file`, it cannot
consume the custom argument, and that is fed eventually to original `ld`, where
the arguments are finally extracted.
I wonder if it makes sense to extract the arguments earlier in the toolchain.
The users sometimes want to use custom `ld` script, and I don't think they
should handle `@file` themselves.
