From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26100 invoked by alias); 19 Apr 2010 17:21:11 -0000 Received: (qmail 26077 invoked by uid 22791); 19 Apr 2010 17:21:07 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Apr 2010 17:21:02 +0000 Received: by vws17 with SMTP id 17so395015vws.0 for ; Mon, 19 Apr 2010 10:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.44.198 with HTTP; Mon, 19 Apr 2010 10:21:00 -0700 (PDT) In-Reply-To: <201004182132.o3ILWqtn029873@glazunov.sibelius.xs4all.nl> References: <20100417161115.GA25919@intel.com> <201004171625.o3HGPc93029549@glazunov.sibelius.xs4all.nl> <201004182132.o3ILWqtn029873@glazunov.sibelius.xs4all.nl> Date: Mon, 19 Apr 2010 17:21:00 -0000 Received: by 10.220.107.26 with SMTP id z26mr3783112vco.31.1271697660106; Mon, 19 Apr 2010 10:21:00 -0700 (PDT) Message-ID: Subject: Re: PATCH: PR corefiles/11511: gcore doesn't work with orig_rax on Linux/amd64 From: "H.J. Lu" To: Mark Kettenis , "H. Peter Anvin" Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00564.txt.bz2 On Sun, Apr 18, 2010 at 2:32 PM, Mark Kettenis wr= ote: >> Date: Sat, 17 Apr 2010 11:50:11 -0700 >> From: "H.J. Lu" >> >> On Sat, Apr 17, 2010 at 9:25 AM, Mark Kettenis = wrote: >> >> Date: Sat, 17 Apr 2010 09:11:15 -0700 >> >> From: "H.J. Lu" >> >> >> >> This patch adds orig_rax support to amd64_linux_gregset_reg_offset. >> >> amd64 has both tdep->gregset_reg_offset/tdep->gregset_num_regs and >> >> amd64_native_gregset64_reg_offset/amd64_native_gregset64_num_regs. = =A0They >> >> are identical. There is no need to keep both. =A0This patch also remo= ves >> >> amd64_native_gregset64_reg_offset/amd64_native_gregset64_num_regs. OK >> >> to install? >> > >> > No. =A0I want to keep the -nat.c and -tdep.c code separate. >> >> Can I replace amd64_linux_gregset64_reg_offset with >> amd64_linux_gregset_reg_offset, like amd64nbsd-nat.c >> and amd64obsd-nat.c? > > We can discuss that, yes. =A0The way the code is organized now, at least > native debugging will continue to work if the layout of the trap frame > in the Linux kernel were to change. =A0At least in the past there was > some fear that this would happen. =A0That danger is probably small; I'm > not even sure if the data structure for PTRACE_GETREGS is even linked > to the trap frame layout anymore. > > Of course the benefit of doing so is that if the kernel ABI is ever > broken GDB will completely stop working on Linux instead of just being > partly broken. > > Any other people have an opinion about this? > I am CCing Peter, who is the Linux x86 kernel maintainer. We have 2 general-purpose register maps in GDB. One is in nat.c: /* Mapping between the general-purpose registers in GNU/Linux x86-64 `struct user' format and GDB's register cache layout. */ static int amd64_linux_gregset64_reg_offset[] =3D It is used for reading/writing registers from/to kernel. One is in tdep.c: /* Mapping between the general-purpose registers in `struct user' format and GDB's register cache layout. */ /* From . */ static int amd64_linux_gregset_reg_offset[] =3D It is use for reading/writing core dump. Both are mappings between `struct user' and GDB's register cache. It is very unlikely that the current x86 Linux kernel ABI for accessing `struct user' will change. If the kernel ABI does need to change for whatever reason, the new interface will be introduced. This applies to both i386 and x86-64 Linux kernel. I'd like to keep a single map between the general-purpose registers in `struct user' format and GDB's register cache for i386/x86-64 Linux. Will such a patch acceptable? Thanks. --=20 H.J.