lldb: Fix usage of sve functions on arm64

[manojgupta]

Summary

Use correct internal sve functions for arm64.
Otherwise, when cross-compling lld for AArch64 there are build
errors like:
NativeRegisterContextLinux_arm64.cpp:936:11:

error: use of undeclared identifier 'sve_vl_valid

NativeRegisterContextLinux_arm64.cpp:63:28:

error: variable has incomplete type 'struct user_sve_header'

[omjavaid]

HI Manoj
Which linux distro are you using for your cross build? I am wondering which version of gcc (aarch64-linux-gnu) are you using for your cross compilation build.
I believe sve headers are not defined in older versions of gcc or its packaged sysroot causing cross compilation build to break.
All sve:: functions and defines are just a make shift arrangement to accommodate build environment which dont have SVE headers/functions defined.

[manojgupta]

I am building on ChromeOS. We only have headers from linux kernel 4.14 available in our build system (The actual running kernel could be a higher version).
But given these functions/struct definitions (sve::<foo>) are already available and used, why are they not used consistently?

e.g. https://source.chromium.org/chromium/external/github.com/llvm/llvm-project/+/main:lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp;l=99
already uses sve::vl_valid and there are uses of sve::user_sve_header as well.

[manojgupta]

Are there any objecttions? This patch is only making a consistent use of pre-existing and already in-use APIs/struct defintions.

[DavidSpickett]

I don't know enough to approve, Omair is the expert here.

[omjavaid]

In D148752#4283899, @manojgupta wrote:

I am building on ChromeOS. We only have headers from linux kernel 4.14 available in our build system (The actual running kernel could be a higher version).
But given these functions/struct definitions (sve::<foo>) are already available and used, why are they not used consistently?

e.g. https://source.chromium.org/chromium/external/github.com/llvm/llvm-project/+/main:lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp;l=99
already uses sve::vl_valid and there are uses of sve::user_sve_header as well.

sve:: namespace introduced SVE helpers from linux headers into LLDB just to avoid the problems such as the one you encountered. The only issue here is that we actually dont want to keep multiple copies of sve headers for ever and want to make sure that every use-case can pull SVE headers from linux headers and we can eventually remove the LLDB copy of these headers.

I am approving this patch but be aware that we may consider removing all sve:: helpers from LLDB in future.

[manojgupta]

Thanks, regarding sve from Linux headers, LLVM currently supports building with GCC 7.1 or clang 5.0 and both were released in 2017. SVE support in Linux kernel believe was added in Linux kernel 4.19 timeframe iso maybe late 2018.
If SVE needs to be built from recent headers as a pre-requisite, then the Linux headers version requirement must also be added to llvm docs at https://llvm.org/docs/GettingStarted.html.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
     const ArchSpec &target_arch, NativeThreadLinux &native_thread) {
   switch (target_arch.GetMachine()) {
   case llvm::Triple::arm:
     return std::make_unique<NativeRegisterContextLinux_arm>(target_arch,
                                                             native_thread);
   case llvm::Triple::aarch64: {
     // Configure register sets supported by this AArch64 target.
     // Read SVE header to check for SVE support.
-    struct user_sve_header sve_header;
+    struct sve::user_sve_header sve_header;
     struct iovec ioVec;
     ioVec.iov_base = &sve_header;
     ioVec.iov_len = sizeof(sve_header);
     unsigned int regset = NT_ARM_SVE;
 
     Flags opt_regsets;
     if (NativeProcessLinux::PtraceWrapper(PTRACE_GETREGSET,
                                           native_thread.GetID(), &regset,
else {
       // Target has SVE enabled, we will read and cache SVE ptrace data
       error = ReadAllSVE();
       if (error.Fail())
         return error;
 
       if (GetRegisterInfo().IsSVERegVG(reg)) {
         uint64_t vg_value = reg_value.GetAsUInt64();
 
-        if (sve_vl_valid(vg_value * 8)) {
+        if (sve::vl_valid(vg_value * 8)) {
           if (m_sve_header_is_valid && vg_value == GetSVERegVG())
             return error;
 
           SetSVERegVG(vg_value);
 
           error = WriteSVEHeader();
           if (error.Success())
             ConfigureRegisterContext();
Status NativeRegisterContextLinux_arm64::WriteAllRegisterValues(
 
   // Verify if register data may contain SVE register values.
   bool contains_sve_reg_data =
       (data_sp->GetByteSize() > (reg_data_min_size + GetSVEHeaderSize()));
 
   if (contains_sve_reg_data) {
     // We have SVE register data first write SVE header.
     ::memcpy(GetSVEHeader(), src, GetSVEHeaderSize());
-    if (!sve_vl_valid(m_sve_header.vl)) {
+    if (!sve::vl_valid(m_sve_header.vl)) {
       m_sve_header_is_valid = false;
       error.SetErrorStringWithFormat("NativeRegisterContextLinux_arm64::%s "
                                      "Invalid SVE header in data_sp",
                                      __FUNCTION__);
       return error;
     }
     m_sve_header_is_valid = true;
     error = WriteSVEHeader();
if (error.Success()) {
         m_sve_state = SVEState::FPSIMD;
       else if ((m_sve_header.flags & sve::ptrace_regs_mask) ==
                sve::ptrace_regs_sve)
         m_sve_state = SVEState::Full;
 
       // On every stop we configure SVE vector length by calling
       // ConfigureVectorLength regardless of current SVEState of this thread.
       uint32_t vq = RegisterInfoPOSIX_arm64::eVectorQuadwordAArch64SVE;
-      if (sve_vl_valid(m_sve_header.vl))
+      if (sve::vl_valid(m_sve_header.vl))
         vq = sve::vq_from_vl(m_sve_header.vl);
 
       GetRegisterInfo().ConfigureVectorLength(vq);
       m_sve_ptrace_payload.resize(sve::PTraceSize(vq, sve::ptrace_regs_sve));
     }
   }
 }