Re: PATCH: PR corefiles/11511: gcore doesn't work with orig_rax on Linux/amd64

[Roland McGrath <roland at redhat dot com>]

The "struct user" layout per se is only used for PTRACE_PEEKUSR/POKEUSR.
(And for a.out core dumps, for which support still existing is questionable.)

On x86, the only thing for which PEEKUSR/POKEUSR is the recommended (and
sole available) method of access is u_debugreg.  That use is the only thing
for which you really need to know "struct user" offsets per se.  If you do
use PEEKUSR/POKEUSR for general register access, the leading portion of
"struct user" is "struct user_regs_struct".  Only that leading portion and
u_debugreg are accessible via PEEKUSR/POKEUSR.

On x86, "struct user_regs_struct" matches the official "primary regset"
layout.  This is what PTRACE_GETREGS/SETREGS uses (on x86--the definitions
of such "legacy" ptrace requests are unfortunately quite idiosyncratic on
each arch beyond the arch's official regset layouts).

In Linux across the board (since 2.6.25 or so), there is one official
canonical layout for each "regset" and this matches the formats used in ELF
core files.  We use the NT_* type codes to refer to which regset you mean.
The "primary regset" layout corresponds to the NT_PRSTATUS note's pr_reg
field--on all machines, that's the one with the general registers.  All
other regsets exactly match the layout of the whole note segment
(NT_PRFPREG, etc.) as found in core files.  The expectation is that any and
all new facilities will use these formats.  Any old ptrace requests that
use different layouts are only kept for backward compatibility.  When new
kinds of register data are added, this will add a new NT_* code and
corresponding layout that is used both for core dumps and for debugging.

In the most recent Linux (only since 2.6.33), there is a generic pair of
requests, PTRACE_GETREGSET and PTRACE_SETREGSET.  This is now the preferred
way to access all user register data.  (The x86 debug registers and similar
things do not form part of the state visible to the user-mode thread and
hence are not part of any "regset".)  This is already the only method for
new kinds of register data such as NT_X86_XSTATE (the only way to get the
high halves of ymm registers, for example).  For all machines, if they CC
me as generic ptrace maintainer, I'll NAK any additions of new one-off
requests in favor of making PTRACE_GETREGSET work right for each arch.
Those requests take the NT_* code to select which regset you want.

These new requests have another wrinkle for biarch machines like x86.
This may be better or worse for you in practice, depending on how you
organize things in your application.  Previous ptrace requests always
referred to the tracer's view of the machine regardless of the tracee's
view.  That is, a 64-bit process calling ptrace always sees the 64-bit
register formats for PTRACE_PEEKUSR, PTRACE_GETREGS, etc.  When dealing
with a 32-bit tracee you just have to know how to interpret a subset of
the 64-bit data as equivalent to 32-bit register data.  In the new
requests, we take the opposite tack.  PTRACE_[GS]ETREGSET always refer
to the tracee's view of its regsets, regardless of what kind of process
makes the ptrace calls.  That is, a 64-bit process tracing a 32-bit
process sees the 32-bit register formats and a 32-bit process tracing a
64-bit process sees the 64-bit register formats.  This has some
advantages and one arcane disadvantage I can elaborate on if you want.


Thanks,
Roland