Provide a (conditional) support for the new PT_GETXSTATE
and PT_SETXSTATE ptrace() requests, and use them to implement getting
and setting YMM registers. The functions used for splitting
and recombining YMM register data are based on matching functions
in FreeBSD plugin, with some simplification and updates to match NetBSD
structures.
Details
Diff Detail
Event Timeline
Rebased for changes in NativeRegisterContextNetBSD_x86_64::GetSetForNativeRegNum(), and removed the conditions there.
We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P). The rest seems pretty straight-forward, though you're repeating the patterns that I find really reduntant/annoying. Eg. I don't see the reason to check the null-ness of the XState buffer. It sounds like it should be a hard error for someone to call ReadXState without bothering to arrange for the storage buffer to exist.
lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp | ||
---|---|---|
251 | Why would we ever want to do this? |
Hmm, I guess that's doable if we pass the relevant struct fields as pointers.
The rest seems pretty straight-forward, though you're repeating the patterns that I find really reduntant/annoying. Eg. I don't see the reason to check the null-ness of the XState buffer. It sounds like it should be a hard error for someone to call ReadXState without bothering to arrange for the storage buffer to exist.
Yeah, I guess that's something I can fix globally first.
lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp | ||
---|---|---|
251 | I was asking myself the exact same thing! But the code is present both on Linux and FreeBSD, so I presumed there is some fancy use case I have no clue about. |
Maybe have GetYMM(unsigned num, YMM& reg)/SetYMM(unsigned num, const YMM ®) methods on the XSAVE struct ?
The rest seems pretty straight-forward, though you're repeating the patterns that I find really reduntant/annoying. Eg. I don't see the reason to check the null-ness of the XState buffer. It sounds like it should be a hard error for someone to call ReadXState without bothering to arrange for the storage buffer to exist.
Yeah, I guess that's something I can fix globally first.
Sounds great.
lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp | ||
---|---|---|
251 | Yeah, I don't think that's a safe assumption around here. :) |
We aren't using XSAVE struct. We are using NetBSD-specific struct xstate that has guaranteed fixed offsets.
Ah, right, I forgot about that part. In that case, it's probably not worth doing that...
lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp | ||
---|---|---|
251 | Right now x86 supports only LE on NetBSD. |
I don't know whether the code is correct for NetBSD, but it looks ok from a general readability perspective.
Why would we ever want to do this?