| Issue |
138717
|
| Summary |
lldb-server crashes on AArch64 which has SME but not SVE
|
| Labels |
lldb,
backend:AArch64
|
| Assignees |
|
| Reporter |
DavidSpickett
|
Relates to https://github.com/llvm/llvm-project/pull/135563
I'm running Arm's Foundation Model via shrinkwrap with the following added to the v9.5-a config:
```
$ git diff
diff --git a/config/arch/v9.5.yaml b/config/arch/v9.5.yaml
index 789e64f..fd29552 100644
--- a/config/arch/v9.5.yaml
+++ b/config/arch/v9.5.yaml
@@ -16,3 +16,16 @@ run:
params:
-C cluster0.has_arm_v9-5: 1
-C cluster1.has_arm_v9-5: 1
+ -C cluster0.has_sve : 1
+ -C cluster1.has_sve : 1
+ -C cluster0.sve.has_sme2 : 0
+ -C cluster1.sve.has_sme2 : 0
+ -C cluster0.sve.has_sme : 1
+ -C cluster1.sve.has_sme : 1
+ -C cluster0.sve.has_sve2 : 1
+ -C cluster1.sve.has_sve2 : 1
+ -C cluster0.sve.sme_only : 1
+ -C cluster1.sve.sme_only : 1
+ -C cluster0.sve.has_sme_fa64: 1
+ -C cluster1.sve.has_sme_fa64: 1
```
Currently SME is disabled in the kernel but for issues that shouldn't break lldb, not like this anyway. So I have patched it back in:
```
$ git diff
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a182295e6f08..27437f13154e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2285,7 +2285,6 @@ config ARM64_SME
bool "ARM Scalable Matrix Extension support"
default y
depends on ARM64_SVE
- depends on BROKEN
help
The Scalable Matrix Extension (SME) is an extension to the AArch64
execution state which utilises a substantial subset of the SVE
```
The cpuinfo reported is:
```
Features : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimdd
p asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme
smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc mops hbc poe
```
Note all the `sme.*` features and no `sve.*` features.
This means the processor has SME but you cannot access the SVE register file outside of streaming mode or use SVE instructions. This is probably what the Apple M4 has, but I don't have one to confirm exactly.
When I start lldb-server it crashes immediately:
```
$ ./lldb-server gdbserver 0.0.0.0:1234 -- /tmp/test.o
/usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:1045: reference std::vecto
r<unsigned int>::operator[](size_type) [_Tp = unsigned int, _Alloc = std::allocator<unsigned int>]: Asser
tion '__n < this->size()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrac
e.
Stack dump:
0. Program arguments: ./lldb-server gdbserver 0.0.0.0:1234 -- /tmp/test.o
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var
`LLVM_SYMBOLIZER_PATH` to point to it):
0 lldb-server 0x0000aaaaaaf78330
1 lldb-server 0x0000aaaaaaf7635c
2 lldb-server 0x0000aaaaaaf78a3c
3 linux-vdso.so.1 0x0000fffff7ffa7dc __kernel_rt_sigreturn + 0
4 libc.so.6 0x0000fffff77ff200
5 libc.so.6 0x0000fffff77ba67c raise + 28
6 libc.so.6 0x0000fffff77a7130 abort + 228
7 lldb-server 0x0000aaaaaaf0bfb0
8 lldb-server 0x0000aaaaab0da9a8
9 lldb-server 0x0000aaaaaafc09f4
10 lldb-server 0x0000aaaaaafc86bc
11 lldb-server 0x0000aaaaaafc84f0
12 lldb-server 0x0000aaaaaafaaa4c
13 lldb-server 0x0000aaaaaafaa78c
14 lldb-server 0x0000aaaaaafa9340
15 lldb-server 0x0000aaaaab018d90
16 lldb-server 0x0000aaaaaaf0916c
17 lldb-server 0x0000aaaaaaf0b054
18 lldb-server 0x0000aaaaaaf11dac
19 libc.so.6 0x0000fffff77a73fc
20 libc.so.6 0x0000fffff77a74cc __libc_start_main + 152
21 lldb-server 0x0000aaaaaaf08d70
Aborted
```
If I symbolise this:
```
$ ./bin/llvm-symbolizer --obj=./bin/lldb-server --adjust-vma=0xaaaaaaaa0000 0x0000aaaaaaf78330 0x0000aaaaaaf7635c 0x0000aaaaaaf78a3c 0x0000fffff7ffa7dc 0x0000fffff77ff200 0x0000fffff77ba67c 0x0000fffff77a7130 0x0000aaaaaaf0bfb0 0x0000aaaaab0da9a8 0x0000aaaaaafc09f4 0x0000aaaaaafc86bc 0x0000aaaaaafc84f0 0x0000aaaaaafaaa4c 0x0000aaaaaafaa78c 0x0000aaaaaafa9340 0x0000aaaaab018d90 0x0000aaaaaaf0916c 0x0000aaaaaaf0b054 0x0000aaaaaaf11dac 0x0000fffff77a73fc 0x0000fffff77a74cc 0x0000aaaaaaf08d70
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
??:0:0
llvm::sys::RunSignalHandlers()
??:0:0
SignalHandler(int, siginfo_t*, void*)
Signals.cpp:0:0
??
??:0:0
??
??:0:0
??
??:0:0
??
??:0:0
llvm::support::detail::provider_format_adapter<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>::~provider_format_adapter()
lldb-gdbserver.cpp:0:0
RegisterInfoPOSIX_arm64::IsSVEReg(unsigned int) const
??:0:0
lldb_private::process_linux::NativeRegisterContextLinux_arm64::ConfigureRegisterContext()
??:0:0
lldb_private::process_linux::NativeThreadLinux::SetStopped()
??:0:0
lldb_private::process_linux::NativeThreadLinux::SetStoppedBySignal(unsigned int, siginfo_t const*)
??:0:0
lldb_private::process_linux::NativeProcessLinux::AddThread(unsigned long, bool)
??:0:0
lldb_private::process_linux::NativeProcessLinux::NativeProcessLinux(int, int, lldb_private::NativeProcessProtocol::NativeDelegate&, lldb_private::ArchSpec const&, lldb_private::process_linux::NativeProcessLinux::Manager&, llvm::ArrayRef<int>)
??:0:0
lldb_private::process_linux::NativeProcessLinux::Manager::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&)
??:0:0
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
??:0:0
handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&, llvm::ArrayRef<llvm::StringRef>)
??:0:0
main_gdbserver(int, char**)
??:0:0
main
??:0:0
??
??:0:0
??
??:0:0
_start
??:0:0
```
We crashed in something related to SVE registers. Probably we tried to lookup a register ID in an empty list, because lldb saw that we don't have SVE, and therefore didn't check for streaming SVE either.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
