[all-commits] [llvm/llvm-project] 6d6416: return-object-by-reference ("non trivial") xfail o...

[Jason Molenda via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 6d64162a2d0df2230faf02ff7ee677c448faf4af
      https://github.com/llvm/llvm-project/commit/6d64162a2d0df2230faf02ff7ee677c448faf4af
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2019-12-11 (Wed, 11 Dec 2019)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/lang/cpp/trivial_abi/TestTrivialABI.py
    M lldb/packages/Python/lldbsuite/test/lang/cpp/trivial_abi/main.cpp
    M lldb/source/Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.cpp

  Log Message:
  -----------
  return-object-by-reference ("non trivial") xfail on arm64 in TestTrivialABI.py

I don't think this test case can be handled correctly on AAPCS64.
The ABI says that the caller passes the address of the return object
in x8.  x8 is a caller-spilled (aka "volatile") register, and the
function is not required to preserve x8 or to copy the address back
into x8 on function exit like the SysV x86_64 ABI does with rax.
(from aapcs64: "there is no requirement for the callee to preserve the
value stored in x8")

>From my quick reading of ABISysV_arm64, I worry that it may actually be
using the value in x8 at function exit, assuming it still has the
address of the return object -

    if (is_return_value) {
      // We are assuming we are decoding this immediately after returning from
      // a function call and that the address of the structure is in x8
      reg_info = reg_ctx->GetRegisterInfoByName("x8", 0);

This will work on trivial test programs / examples, but if the function
does another function call, or overwrites x8 as a scratch register, lldb
will provide incorrect values to the user.

ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value
as unavailable so we're providing incorrect values to the user all
the time.  I expect my fix will be to make ABIMacOSX_arm64 flag
the return value as unretrievable, unless I've misread the ABI.