From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10869 invoked by alias); 6 May 2003 18:27:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10856 invoked from network); 6 May 2003 18:27:28 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 6 May 2003 18:27:28 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h46IRRQd005454 for ; Tue, 6 May 2003 11:27:27 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 May 2003 11:27:09 -0700 Received: from apple.com (vpn-scv-x3-69.apple.com [17.219.194.69]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h46IRL8t012193; Tue, 6 May 2003 11:27:21 -0700 (PDT) Message-ID: <3EB8007D.4050805@apple.com> Date: Tue, 06 May 2003 18:27:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner CC: gdb@sources.redhat.com Subject: Re: LSI 33k ? References: <1030506123427.ZM24517@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00080.txt.bz2 It might never have worked, or the correct code might not be in CVS anywhere. I have a vague memory that it was for Array Technology ca 1992-3, and in those earlier days of Cygnus, some shipments were made "by hand", and not all of the customer's bits exactly corresponded with a CVS tag. remote-array.c might also have an answer in the form of jiggered-around register numbering. Stan Kevin Buettner wrote: >Does anyone know anything about the LSI 33k? Okay, more specifically, did >support for this core ever actually work in GDB? > >In mips-tdep.c, I see the following: > > /* Names of LSI 33k registers. */ > > char *mips_lsi33k_reg_names[] = { > "epc", "hi", "lo", "sr", "cause","badvaddr", > "dcic", "bpc", "bda", "", "", "", "", "", > "", "", "", "", "", "", "", "", > ... > >With the exception of IRIX, the first line for all of the other regname >sets look like this: > > "sr", "lo", "hi", "bad", "cause","pc", > >I'm not concerned about IRIX, because BADVADDR_REGNUM, CAUSE_REGNUM, >PC_REGNUM, etc. are redefined in the appropriate tm-*.h file. > >The LSI 33k rearranges these registers, apparently even the PC_REGNUM >value, but nowhere do I see a PC_REGNUM definition that's specific to >the LSI 33k. This is bad because if the LSI 33k registers are really >laid out as indicated by lsi33_reg_names[], then there's no way that >GDB is actually obtaining the correct PC value whenever it uses PC_REGNUM. >(It'll be using the "baddvaddr" value...) > >I thought for a while that perhaps the LSI 33k was simply bit-rotted, >but after doing some digging in the old Cygnus CVS repository, I don't >see how it could have ever worked. > >Does anyone know? > >Kevin > > >