[CRIU] [PATCH] Wire up AArch64 TLS dump and restore
Christopher Covington
cov at codeaurora.org
Tue Feb 18 07:07:05 PST 2014
On 02/17/2014 12:37 PM, Alexander Kartashov wrote:
> On 02/15/2014 03:18 AM, Christopher Covington wrote:
>> I wonder why ptrace isn't being used by existing architecture
>> ports for TLS registers
> That's my fault: I haven't known that it's possible to fetch
> the value of the TLS register using ptrace(). I shall consider
> moving the TLS fetchr and store routines to ptrace().
I've not tested it out for more than a trivial case--it may may not work
exactly right in all cases, but I would suspect that if GDB is using it, it
should be pretty robust.
My guess would be that x86_64 set the example of using GETREGS because at the
time it was better documented than GETREGSET. From a brief glance through the
kernel code, GETREGS doesn't include TLS registers, so an
architecture-specific method was employed. I only stumbled across the TLS
support case in the kernel code for GETREGSET because I was tracing through
how your AArch64 patches worked, which were influenced by the fact that the
AArch64 kernel code doesn't implement GETREGS.
It's certainly easier to add support for a new architecture when it follows
the example of the other ports, so I wouldn't recommend gating the AArch64
support on using ptrace for TLS, but maybe down the road if all of the
architectures moved to GETREGSET, more of the register dumping code could
become generic across architectures.
Feel free to edit my commentary in the commit message (or squash the patch
into yours) when merging. It probably belonged in a cover letter rather than
the patch itself.
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
More information about the CRIU
mailing list