From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14978 invoked by alias); 29 Nov 2003 02:07:31 -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 14969 invoked from network); 29 Nov 2003 02:07:28 -0000 Received: from unknown (HELO jifvik.dyndns.org) (81.104.194.28) by sources.redhat.com with SMTP; 29 Nov 2003 02:07:28 -0000 Received: from eCosCentric.com (garibaldi.jifvik.org [172.31.1.2]) by jifvik.dyndns.org (Postfix) with ESMTP id 3856737485 for ; Sat, 29 Nov 2003 02:07:26 +0000 (GMT) Message-ID: <3FC7FF5D.7060906@eCosCentric.com> Date: Sat, 29 Nov 2003 02:07: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: gdb-patches@sources.redhat.com Subject: powerpc remote target registers Content-Type: multipart/mixed; boundary="------------080305070104040006020009" X-SW-Source: 2003-11/txt/msg00617.txt.bz2 This is a multi-part message in MIME format. --------------080305070104040006020009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2883 I've been having a problem where (via the MI interface, but that's irrelevant), GDB (6.0) would report e.g. "register vr8 not available", where "8" may be any number, changing each time the program is stepped or restarted. Register vr8 is an altivec register and my remote target does not support altivec. What appears to be the problem is that the binaries built by powerpc-eabi-gcc are marked as being for architecture powerpc, machine "common" (by BFD in the ELF header). This tells GDB that it supports certain register sets, including altivec, i.e. vr* registers. In fact the target doesn't support altivec, and the target sends a short packet compared to GDB's expectations, but that shouldn't matter as by rights GDB should just ignore registers the target doesn't supply, right? Certainly code appears to handle that case without a warning. However, at the end of remote_fetch_registers(), it does a check for if any of the registers start with an "x" character. If it does, it is marked as invalid. However the buffer containing the register set is never initialised, and so contains random junk. The size of the altivec register set makes it more likely to find an "x" somewhere (although curiously it does happen more frequently than I'd expect). Which also explains it being a different register most times it's run. 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. Another possibility is for the remote stub to send the much longer packets (nearly 2kb!) including the altivec registers, however this may cause backward compatibility problems with older GDBs which is very bad indeed for us. Instead GDB should be able to cope with stubs not returning full register sets despite expectations. So, for that reason I suggest the attached patch. Sorry for the long e-mail for a one-liner :-). Thanks, Jifl 2003-11-29 Jonathan Larmour * remote.c (remote_fetch_registers): Clear buf to avoid treating junk as register data. -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine --------------080305070104040006020009 Content-Type: text/plain; name="remoteclearbuf.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="remoteclearbuf.patch" Content-length: 570 --- remote.c~ 2003-06-30 16:51:49.000000000 +0100 +++ remote.c 2003-11-29 01:50:05.000000000 +0000 @@ -3440,10 +3440,11 @@ remote_fetch_registers (int regnum) internal_error (__FILE__, __LINE__, "Attempt to fetch a non G-packet register when this " "remote.c does not support the p-packet."); } + memset (buf, 0, rs->remote_packet_size); sprintf (buf, "g"); remote_send (buf, (rs->remote_packet_size)); /* Save the size of the packet sent to us by the target. Its used as a heuristic when determining the max size of packets that the --------------080305070104040006020009--