From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11850 invoked by alias); 22 Apr 2002 19:30:52 -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 11831 invoked from network); 22 Apr 2002 19:30:45 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 22 Apr 2002 19:30:45 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Mon, 22 Apr 2002 12:29:08 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g3MJUi1S023122; Mon, 22 Apr 2002 12:30:44 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id MAA29565; Mon, 22 Apr 2002 12:30:43 -0700 (PDT) To: "Alexandre Oliva" cc: gdb-patches@sources.redhat.com, fche@redhat.com, echristo@redhat.com Subject: Re: MIPS simulator initializes LSI pmon vector table with code References: From: cgd@broadcom.com Date: Mon, 22 Apr 2002 12:30:00 -0000 In-Reply-To: "Alexandre Oliva"'s message of "22 Apr 2002 16:08:54 -0300" Message-ID: MIME-Version: 1.0 X-WSS-ID: 10DABB0E269820-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00805.txt.bz2 At 22 Apr 2002 16:08:54 -0300, Alexandre Oliva wrote: > I asked fche, and he agreed my fix was reasonable, so I checked it in, > just to have it reverted by one of the maintainers, and then have the > other maintainers say I should have done exactly what I did :-( Well, what I was suggesting was meant to be a prefix for "and then submit it via normal channels" which you didn't do. 8-) > > If you go back to the original code in public rev 1.1, what you'll > > find is that the writes of 'halt' to the BFC addrs above was done > > _before_ the pmon/lsipmon loop to write the values. > > Except that there was no pmon/lsipmon in rev 1.1. Only idtmon. Excuse me? There were no variables to control use of the blocks of code, but the blocks of code were there and run unconditionally, unless i'm going blind... lines 529 - 605 of rev 1.1, or thereabouts. > According to a comment in the code, that was already in rev 1.1: > > /* The PMON monitor uses the same address space, but rather than > branching into it the address of a routine is loaded. We can > cheat for the moment, and direct the PMON routine to IDT style > instructions within the monitor space. This relies on the IDT > monitor not using the locations from 0xBFC00500 onwards as its > entry points.*/ > > Clearly, if pmon (and lsipmon) expect the address of the handler to be > written into that space, writing a HALT instruction will get you the > wrong effect. Since AFAICT that range is only used by the lsipmon, I > propose that, instead of just `#if'ing out that code, we actually > remove it. So, go through and look at what the code does: * the PMON support _does not_ uses the memory at 0xbfc00200, except for the halt instructions. its handler address ptrs go at 0xbfc00500. * lsipmon puts the handler addresses at 0xbfc00200. If the handler address setup were run after the halt code init, I believe that would have the right effect. I still don't believe you explained if there's anything special about the LSI MiniRISC parts that makes that 'OK' or 'normal'. On most MIPS parts, like I said, those will be the TLB handlers. (You're apparently using it, which is why you care about this patch; surely you can say what it's trying to do! 8-) If the MiniRISC doesn't have a TLB, that would probably explain it (but i'd like to know for sure, and it should probably be mentioned in a comment). Regardless, if that's what the monitor does, that's what the monitor does, and that should be supported, but not at the expense of ripping the 'halt's out for other monitors (which is what you did). > > The action that the 'halt'-writing code accomplishes is that it > > arranges to halt the simulator when you get one of these exceptions. > > Nope, it arranges for an invalid instruction to be executed, or a > branch to an invalid address to be taken, if you get the monitor > conventions wrong. That's what the _bug_, for your particular monitor, causes. I believe what I stated _is_ the goal of the halt-writing code. 8-) > The right thing to do is to not write code into the table if it's not > supposed to contain code. So, (1) It's fairly obvious that for other monitors that location _should_ contain code. (2) you've not explained why the lsipmon monitor _doesn't_ contain code there, at a location where the MIPS architecture says _should_ contain executable code. (3) If you do the halt-writing first, followed by the pmon/lsipmon vector init (as revision 1.1 of the file did), I _believe_ all would be OK. I think you have more than enough information to know how fix the problem properly, at this point. (I'd still like to know why lsipmon thinks it's OK to put other-than-code at that vector.) chris