Fix lldb-server build failure on mips

[raj.khem]

Summary

This helps fixing lldb-server build regression

/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/clang/13.0.0-r0/recipe-sysroot-native/usr/bin/mips-yoe-linux-musl/mips-yoe-linux-musl-ld: lib/liblldbPluginProcessLinux.a(NativeThreadLinux.cpp.o): in function `lldb_private::process_linux::NativeThreadLinux::NativeThreadLinux(lldb_private::process_linux::NativeProcessLinux&, unsigned long long)':
NativeThreadLinux.cpp:(.text._ZN12lldb_private13process_linux17NativeThreadLinuxC2ERNS0_18NativeProcessLinuxEy+0x74): undefined reference to `lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(lldb_private::ArchSpec const&, lldb_private::process_linux::NativeThreadLinux&)'
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/clang/13.0.0-r0/recipe-sysroot-native/usr/bin/mips-yoe-linux-musl/mips-yoe-linux-musl-ld: NativeThreadLinux.cpp:(.text._ZN12lldb_private13process_linux17NativeThreadLinuxC2ERNS0_18NativeProcessLinuxEy+0x7c): undefined reference to `lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(lldb_private::ArchSpec const&, lldb_private::process_linux::NativeThreadLinux&)'
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

[DavidSpickett]

I assume this is caused by the removal of the specific NativeRegisterContextLinux_mips and you are building lldb on MIPS but you're going to connect to another debug server (gdb, custom stub etc.).

The problem with doing it this way is then if you build on a supported platform e.g. AArch64 NativeRegisterContextLinux_arm64 we then have two copies of CreateHostNativeRegisterContextLinux. Somehow this isn't an error on my system, and it picks up the one you've added. Meaning that you can't debug a simple hello world.

See the comment in lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h. (though again I'd have expect a hard linker error but anyway) Also the reason CI didn't fail is that lldb is disabled for both of the builds.

I can see the utility in allowing people to build at least lldb (client) on any platform. Perhaps we surround this in the #ifdef that the old mips register context used? Or modify our cmake to allow lldb-server to be disabled. (easier said than done)

[raj.khem]

In D102872#2773106, @DavidSpickett wrote:

I assume this is caused by the removal of the specific NativeRegisterContextLinux_mips and you are building lldb on MIPS but you're going to connect to another debug server (gdb, custom stub etc.).

The problem with doing it this way is then if you build on a supported platform e.g. AArch64 NativeRegisterContextLinux_arm64 we then have two copies of CreateHostNativeRegisterContextLinux. Somehow this isn't an error on my system, and it picks up the one you've added. Meaning that you can't debug a simple hello world.

See the comment in lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h. (though again I'd have expect a hard linker error but anyway) Also the reason CI didn't fail is that lldb is disabled for both of the builds.

I can see the utility in allowing people to build at least lldb (client) on any platform. Perhaps we surround this in the #ifdef that the old mips register context used? Or modify our cmake to allow lldb-server to be disabled. (easier said than done)

yes that will be ok. Although, I think for kind of devices mips is used in, lldb-server is more useful even if it will not support all features.

[glaubitz]

This failure affects 32-bit PowerPC as well. Can we get this fixed?

[glaubitz]

It seems we need this change on all architectures except arm, arm64, ppc64el, s390x and x86_64. Those are the only ones which implement NativeRegisterContextLinux_$ARCH.

See: https://github.com/llvm/llvm-project/tree/main/lldb/source/Plugins/Process/Linux

[labath]

This will create an lldb-server that crashes as soon as it tries to debug something. Maybe it would be better to disable the binary completely (in cmake) for unsupported architectures instead?

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

27 ↗

(On Diff #346855)

This will cause multiple definition errors for architectures that do define this function.

[sylvestre.ledru]

Maybe it would be better to disable the binary completely (in cmake) for unsupported architectures instead?

+1, having an error message like "lldb isn't supported on arch foo" would save hours of work :)

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h

 //===-- NativeRegisterContextLinux.h ----------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef lldb_NativeRegisterContextLinux_h
 #define lldb_NativeRegisterContextLinux_h
 
 #include "Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h"
 #include "lldb/Host/common/NativeThreadProtocol.h"
 
 namespace lldb_private {
 namespace process_linux {
 
 class NativeThreadLinux;
 
 class NativeRegisterContextLinux
     : public virtual NativeRegisterContextRegisterInfo {
 public:
   // This function is implemented in the NativeRegisterContextLinux_* subclasses
   // to create a new instance of the host specific NativeRegisterContextLinux.
   // The implementations can't collide as only one NativeRegisterContextLinux_*
   // variant should be compiled into the final executable.
   static std::unique_ptr<NativeRegisterContextLinux>
   CreateHostNativeRegisterContextLinux(const ArchSpec &target_arch,
-                                       NativeThreadLinux &native_thread);
+                                       NativeThreadLinux &native_thread)
+                                 { return 0; }
 
   // Invalidates cached values in register context data structures
   virtual void InvalidateAllRegisters(){}
 
   struct SyscallData {
     /// The syscall instruction. If the architecture uses software
     /// single-stepping, the instruction should also be followed by a trap to
     /// ensure the process is stopped after the syscall.