From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11889 invoked by alias); 2 Dec 2003 05:23:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11880 invoked from network); 2 Dec 2003 05:23:02 -0000 Received: from unknown (HELO jifvik.dyndns.org) (81.104.194.28) by sources.redhat.com with SMTP; 2 Dec 2003 05:23:02 -0000 Received: from eCosCentric.com (garibaldi.jifvik.org [172.31.1.2]) by jifvik.dyndns.org (Postfix) with ESMTP id BC02837485; Tue, 2 Dec 2003 05:22:58 +0000 (GMT) Message-ID: <3FCC21B2.30000@eCosCentric.com> Date: Tue, 02 Dec 2003 05:23:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4) Gecko/20030703 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: powerpc remote target registers References: <3FC7FF5D.7060906@eCosCentric.com> <3FCB8DDC.30603@gnu.org> In-Reply-To: <3FCB8DDC.30603@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00039.txt.bz2 Andrew Cagney wrote: >> Now, arguably this is a problem with GCC/GAS/GLD: there is a machine >> type specifically for mpc860 with the correct register definitions, >> instead of "common" with the correct register definitions. However >> GCC/GAS don't allow you to set that when compiling objects, and LD >> appears to ignore my request to set it explicitly when linking (using >> -A powerpc:mpc860). That shouldn't really be needed anyway, as it >> should be implied by a compile with -mcpu=860, but GCC doesn't pass >> anything to GAS/the linker to reflect that. Sigh. >> >> However I would say that GDB is also mistaken for not initializing the >> packet buffer in remote_fetch_registers() to 0 first, so that >> registers that aren't supplied by the remote target don't have >> uninitialised data, which may include an "x" in them. > > > I don't think this fixes the bug. It will fill each nibble of the > altivec registers with (0 - '0') instead of zero (you should see this > with "maint print raw-registers"). Ah, it still came up with 0 until I did that so I thought that was it. > Suggest instead changing the for loop filling in regs[] so that it > doesn't run off the end of the NUL terminated buf[] (I think this is the > real bug). But then the registers aren't marked as cached at all, so they're now requested from the target each time you do "info all-registers", even though they come up with 0s. Should I pretend the registers not supplied by the target were 0, or should I mark them as unavailable (i.e. the same as what having an "x" does) so at least it's consistent? Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine