[Lldb-commits] [PATCH] D117928: [lldb] Disable tests for x86 that uses write command on XMM registers

Luís Ferreira via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Sat Jan 22 16:00:48 PST 2022

ljmf00 added a comment.

In D117928#3263319 <https://reviews.llvm.org/D117928#3263319>, @mgorny wrote:

> Ok, so to summarize: there's some CPU families where setting `xmm2..xmm9` via ptrace doesn't work for some reason? That's quite weird. Could it be an `xsave` bug perhaps?

Exactly. `ptrace` with `NT_FPREGSET` doesn't work properly but `NT_X86_XSTATE` does. It makes sense to me that the presence of AVX triggers this, since, from my inspection of the LLDB code, there is a fallback system on `ReadRegisterSet` that tries to use `ptrace` with `NT_X86_XSTATE` and fallbacks to `NT_FPREGSET` if it fails. The call made with `NT_X86_XSTATE` gives me different output on `strace`:

  ptrace(PTRACE_SETREGSET, 213817, NT_X86_XSTATE, {iov_base=0x555597dcd4a0, iov_len=1088}) = 0
  ptrace(PTRACE_GETREGSET, 213817, NT_X86_XSTATE, {iov_base=0x555597dcd4a0, iov_len=1088}) = 0

> FWICS the corresponding read test passes, so apparently setting them directly within the program works.

Yes, I can confirm that. Writing directly to registers is fine and reading them only triggers `PTRACE_GETREGSET` so, it is reading fine. The problem is when `ptrace` is called with `PTRACE_SETREGSET`.
Inspecting the kernel source code I see that `NT_FPREGSET` is triggered by `xfpregs_set` https://github.com/torvalds/linux/blob/master/arch/x86/kernel/fpu/regset.c#L89 . That `memset` seems very suspicious here. Blaming the source code, seems to be before Linux v5.16 .

This makes sense to me since I use Arch with the latest kernel, and a lot of people use LTS versions or outdated versions due to Ubuntu/Debian (according to Wikipedia, unstable Debian uses Linux 5.10.46). I will downgrade the kernel and try to reproduce this. Ultimately, I can try to recompile the kernel without that `memset` and see what happens. I can't find a logical reason in my brain other than wrong offsets? If I didn't calculate it wrongly, the range of bytes is the same size. Would be cool if anyone have any knowledge of the kernel and explain this to me.

> Could you tell us what CPU exactly is this? Ideally paste `/proc/cpuinfo`. I'm pretty sure this test passed successfully on my old Athlon64 that definitely didn't have AVX (or SSE3). Unfortunately, I can't retest it anymore since it died almost 2 years ago.

Is `lscpu` enough? See https://termbin.com/c2pt .

  rG LLVM Github Monorepo



More information about the lldb-commits mailing list