From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15803 invoked by alias); 8 Jul 2008 03:53:13 -0000 Received: (qmail 15790 invoked by uid 22791); 8 Jul 2008 03:53:11 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jul 2008 03:52:50 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 34CD017F453 for ; Tue, 8 Jul 2008 00:40:08 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m683qnV43551302 for ; Tue, 8 Jul 2008 00:52:49 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m683qibp002994 for ; Tue, 8 Jul 2008 00:52:44 -0300 Received: from [9.8.8.213] ([9.8.8.213]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m683qhi5002968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 00:52:44 -0300 Subject: Re: [PATCH] PPC - Stepping off breakpoints in non-stop mode From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Jonathan Larmour Cc: gdb-patches@sourceware.org In-Reply-To: <4872C52C.1020701@eCosCentric.com> References: <4872C52C.1020701@eCosCentric.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 08 Jul 2008 03:53:00 -0000 Message-Id: <1215489163.5333.29.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit 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: 2008-07/txt/msg00110.txt.bz2 Hi Jonathan, Is this an embedded target? > Unfortunately this fails to build due to this warning (in combination with > -Werror): > .../rs6000-tdep.c: In function ‘ppc_displaced_step_fixup’: > .../rs6000-tdep.c:885: warning: passing argument 3 of > ‘regcache_cooked_read_unsigned’ from incompatible pointer type > make[2]: *** [rs6000-tdep.o] Error 1 > > This is because in the following line, current_pc is CORE_ADDR, but > regcache_cooked_read_unsigned's last arg is meant to be a ULONGEST *. > > + regcache_cooked_read_unsigned (regs, gdbarch_pc_regnum (gdbarch), > + ¤t_pc); > > I was thinking of just casting it, but in fact would it be better to be > calling regcache_read_pc() here as well as regcache_write_pc() in the rest > of the patch when operating on the pc? From earlier in this thread, there > was a little discussion about address sizes, so I thought I'd best ask > before submitting a patch, as there could be portability implications and > it might have been done this way for a reason. > > Jifl