LLDB: test_vectorcall fails on FreeBSD

[mgorny]

======================================================================
FAIL: test_vectorcall (TestCCallingConventions.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/mgorny/llvm-project/lldb/test/API/lang/c/calling-conventions/TestCCallingConventions.py", line 67, in test_vectorcall
    self.expect_expr("func(1.0)", result_type="int", result_value="1")
  File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2438, in expect_expr
    value_check.check_value(self, eval_result, str(eval_result))
  File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 290, in check_value
    test_base.assertSuccess(val.GetError())
  File "/usr/home/mgorny/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2474, in assertSuccess
    self.fail(self._formatMessage(msg,
AssertionError: 'expression failed to parse:
error: Couldn't lookup symbols:
  func@@8
' is not success
Config=x86_64-/home/mgorny/llvm-project/build/bin/clang

[llvmbot]

@llvm/issue-subscribers-lldb

[aokblast]

This error is emitted from ld.lld. I have check the output from clang -S and llc, they generate the correct symbol name. However, after linking by lld. The function is replaced from "func@@8" with "func".
I am still checking the error but I think it is caused from the ABI.
Symbol with "@" suffix in GNU stands for the version and "@@" suffix stands for the default version.
I think ld.lld implementation use this semantics and trim the "@@" to resolve original symbol.
"func@@8" -> "func"
This naming convension is clash with the microsoft "__vector_call" which will also generate "@@" suffix.
If it is the case, I don't know if it should be called as a bug.
Update: I think the issue is from here

[Michael137]

Yup this seems to be LLD specific. I can repro this test failure by compiling the test with -fuse-ld=lld. Had to XFAIL this on Linux for our Swift CI bots: swiftlang#8845