From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14211 invoked by alias); 19 Apr 2002 19:48:30 -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 14130 invoked from network); 19 Apr 2002 19:48:25 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 19 Apr 2002 19:48:25 -0000 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g3JJm1v01528; Fri, 19 Apr 2002 12:48:01 -0700 Subject: Re: MIPS simulator initializes LSI pmon vector table with code From: Eric Christopher To: cgd@broadcom.com Cc: aoliva@redhat.com, fche@redhat.com, gdb-patches@sources.redhat.com In-Reply-To: References: <1019238909.1702.35.camel@ghostwheel.cygnus.com> <1019241298.12982.2.camel@ghostwheel.cygnus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 19 Apr 2002 12:48:00 -0000 Message-Id: <1019245609.13014.16.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 X-SW-Source: 2002-04/txt/msg00634.txt.bz2 On Fri, 2002-04-19 at 12:06, cgd@broadcom.com wrote: > At 19 Apr 2002 11:34:58 -0700, Eric Christopher wrote: > > This was support that worked a while back and the change that Alex is > > reverting broke the LSI support. We aren't supporting something new, > > we're fixing something that someone else broke :) > > well, at some point in time perhaps. > > it looks like this code has been in the public cvs tree in some form > forever. > Forever is a very long time. mips16 didn't work in net gcc for more than a year and a half until somebody (me) noticed :) > rev 1.1 did code like this, but it was moved in rev 1.2 (by fche) to > later in the function and made conditional on perhaps the wrong > variables. > OK. > > "change that Alex is reverting" isn't a good description: if he > actually had reverted the change that put those there, he would have > put those calls back in their original locations and let the > subsequent vector-setting code do its work afterward, rather than just > commenting them out. > True. > > I'm still not seeing anything that convinces me that this change is > correct, or even more correct (using the metric of "number of > platforms broken") than what was there before. > OK. I'll let Alex explain the sequence of events that shows that the current code isn't correct, or at least breaks what used to be the "existing" lsi support :) -eric -- Written using state-of-the-rat technology.