From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 556 invoked by alias); 29 Aug 2007 07:26:10 -0000 Received: (qmail 485 invoked by uid 22791); 29 Aug 2007 07:26:09 -0000 X-Spam-Check-By: sourceware.org Received: from omta04ps.mx.bigpond.com (HELO omta04ps.mx.bigpond.com) (144.140.83.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Aug 2007 07:26:00 +0000 Received: from oaamta08ps.mx.bigpond.com ([58.174.192.2]) by omta04ps.mx.bigpond.com with ESMTP id <20070829072557.FULM1991.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com> for ; Wed, 29 Aug 2007 07:25:57 +0000 Received: from bubble.grove.modra.org ([58.174.192.2]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070829072557.IEUL20695.oaamta08ps.mx.bigpond.com@bubble.grove.modra.org>; Wed, 29 Aug 2007 07:25:57 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id E04073A5A06; Wed, 29 Aug 2007 16:55:56 +0930 (CST) Date: Wed, 29 Aug 2007 07:26:00 -0000 From: Alan Modra To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: powerpc-linux biarch corefile support Message-ID: <20070829072556.GA25275@bubble.grove.modra.org> References: <20070825012327.GG31717@bubble.grove.modra.org> <200708282303.l7SN35rM004362@d12av02.megacenter.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708282303.l7SN35rM004362@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.9i 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: 2007-08/txt/msg00509.txt.bz2 On Wed, Aug 29, 2007 at 01:03:05AM +0200, Ulrich Weigand wrote: > In particular, the original code appears to treat CCR, XER, and CTR > as left-aligned, and the others as right-aligned: [snip] > > Your new code makes no such distinction, they're all treated as > right-aligned. > > I wonder whether this change was deliberate? It does appear the > original code is actually wrong; the kernel stores CCR, XER, and > CRT just the same as e.g. NIP and LNK, as far as I can see. I should have mentioned this change. It was deliberate. The old code was just plain wrong (and the reason why "info reg" on a 64-bit core file always showed zero for CR and XER). It was inconsistent too. CTR used right fill in ppc-linux-nat.c:fill_gregset but left fill in ppc-linux-tdep.c:ppc_linux_supply_gregset. I suspect that using left fill for CTR was just a copy and paste error, but the comment Andrew Cagney added seems to indicate he meant to use left-fill for CR and XER. Perhaps the ppc64 linux kernel stored them that way at some stage? I'll ask some kernel experts. > Did you verify that those registers are now handled correctly in > both 64x64 and 32x64 cases (native and core)? Yes. > Also, you missed setting the gpr_size field in a couple of cases: > rs6000-aix-tdep.c:rs6000_aix32_reg_offsets > rs6000-aix-tdep.c:rs6000_aix64_reg_offsets > ppcobsd-nat.c:ppcobsd_reg_offsets Oops, shame on me. I'll fix that. > And, since you're now using gpr_size in the _fpregset routines as > well, I guess ppcobsd_fpreg_offsets would need to set gpr_size too. > However, I think it would be preferable to not use gpr_size in > those routines in the first place; the size of this register is in > fact always 4. However, the fpscr field is 64 bits in struct ucontext on both powerpc64-linux and powerpc-linux, and the definition of PT_FPSCR points to the low 32 bits on powerpc-linux and the full 64-bit word on powerpc64-linux. Since the size passed to ppc_supply_reg and ppc_collect_reg is that of the field, I figured that it ought to be 8 bytes on powerpc64-linux. I could make the size 4 and adjust the offset in ppc64_linux_reg_offsets, but I had ideas of using ppc_greg_offset and ppc_fpreg_offset in place of ppc-linux-nat.c:ppc_register_u_addr, which provides an offset into ucontext. PTRACE_PEEKUSER and PTRACE_POKEUSER bomb on ppc64 if the offset isn't a multiple of 8... -- Alan Modra Australia Development Lab, IBM