From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4554 invoked by alias); 1 Dec 2003 18:52:13 -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 4547 invoked from network); 1 Dec 2003 18:52:13 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 1 Dec 2003 18:52:13 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7B23E2B8F; Mon, 1 Dec 2003 13:52:12 -0500 (EST) Message-ID: <3FCB8DDC.30603@gnu.org> Date: Mon, 01 Dec 2003 18:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Larmour Cc: gdb-patches@sources.redhat.com Subject: Re: powerpc remote target registers References: <3FC7FF5D.7060906@eCosCentric.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00022.txt.bz2 > 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"). 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). Andrew