disable getauxval HWCAP value for ARM64, which indicates Atomics supp…

[rliebig]

Checklist

Which kind of PR do you create?

• This PR only contains minor fixes.
• This PR contains major feature update.
• This PR introduces a new function/api for Qiling Framework.

Coding convention?

• The new code conforms to Qiling Framework naming convention.
• The imports are arranged properly.
• Essential comments are added.
• The reference of the new code is pointed out.

Extra tests?

• No extra tests are needed for this PR.
• I have added enough tests for this PR.
• Tests will be added after some discussion and review.

Changelog?

• This PR doesn't need to update Changelog.
• Changelog will be updated after some proper review.
• Changelog has been updated in my PR.

Target branch?

• The target branch is dev branch.

One last thing

• I have read the contribution guide

---

This change fixes the ARM64 elf loader to not indicate that atomics instructions are supported. The current QEMU version by Unicorn does not support these atomics call, therefore we should also not indicate to processes that this is a good idea.

getauxval values are determined by the kernel documentation like this. Therefore, we need to ensure that HWCAP_ATOMICS is not set.

Mostly the processes do check for support judging from these values like this (example from LIBC). The variable _aarch64_have_lse_atomics is controlled by getauxval.

char __fastcall _aarch64_cas1_acq_rel(int a1, unsigned __int8 a2, atomic_uchar *a3)
{
  int v3; // w16

  if ( _aarch64_have_lse_atomics )
  {
    atomic_compare_exchange_strong(a3, (unsigned __int8 *)&a1, a2);
  }
  else
  {
    v3 = (unsigned __int8)a1;
    do
      a1 = __ldaxr((unsigned __int8 *)a3);
    while ( a1 == v3 && __stlxr(a2, (unsigned __int8 *)a3) );
  }
  return a1;
}

[wtdcode]

LGTM