From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28258 invoked by alias); 20 Apr 2010 22:17:13 -0000 Received: (qmail 28243 invoked by uid 22791); 20 Apr 2010 22:17:11 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Apr 2010 22:17:06 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3KMH27d030527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Apr 2010 18:17:02 -0400 Received: from patootie.sf.frob.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3KMH1GM009882; Tue, 20 Apr 2010 18:17:01 -0400 Received: from magilla.sf.frob.com (magilla.office.frob.com [198.49.250.228]) by patootie.sf.frob.com (Postfix) with ESMTP id 70D04511F; Tue, 20 Apr 2010 15:17:06 -0700 (PDT) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 5A651CF33; Tue, 20 Apr 2010 15:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "H. Peter Anvin" X-Fcc: ~/Mail/linus Cc: "H.J. Lu" , Mark Kettenis , gdb-patches@sourceware.org Subject: Re: PATCH: PR corefiles/11511: gcore doesn't work with orig_rax on Linux/amd64 In-Reply-To: H. Peter Anvin's message of Monday, 19 April 2010 10:27:52 -0700 <4BCC9298.3010100@zytor.com> References: <20100417161115.GA25919@intel.com> <201004171625.o3HGPc93029549@glazunov.sibelius.xs4all.nl> <201004182132.o3ILWqtn029873@glazunov.sibelius.xs4all.nl> <4BCC9298.3010100@zytor.com> Message-Id: <20100420221700.5A651CF33@magilla.sf.frob.com> Date: Tue, 20 Apr 2010 22:17:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00652.txt.bz2 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