From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15142 invoked by alias); 24 Apr 2002 01:24:11 -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 15135 invoked from network); 24 Apr 2002 01:24:10 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 24 Apr 2002 01:24:10 -0000 Received: from free.redhat.lsd.ic.unicamp.br (vpn3-1.sfbay.redhat.com [172.16.25.1]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g3O1NZv23153; Tue, 23 Apr 2002 18:23:35 -0700 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g3O1O1U20224; Tue, 23 Apr 2002 22:24:01 -0300 To: cgd@broadcom.com 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: Alexandre Oliva Organization: GCC Team, Red Hat Date: Tue, 23 Apr 2002 18:24:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00898.txt.bz2 On Apr 22, 2002, cgd@broadcom.com wrote: > 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-) Point taken; I think I have already apologized for crossing the line. If I didn't, please accept my apologies. If I did, please accept them again :-) >> > 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... Sorry, I looked only at the diff between 1.1 and 1.2, and I admit I must be confused. > * 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. Except that some handlers would be incorrectly set with remnants of half halt sequences. > 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-) Now I have to confess that I have absolutely no idea of what's going on in there, and that I had never heard of these monitors before. All I know is that I was debugging some totally unrelated code for a lsipmon toolchain, and it was crashing at the end. I eventually figured out that statement was overwriting the entry for the `write' service that had been put there in the previous loop, and figured the `???' comment just before the code meant it was wrong. In my book, failing to halt on invocation of unregistered services in certain configurations is much better than failing to run any program at all on other configurations, so I came up with this patch, ran it through Frank that agreed it looked reasonable and put it in as, well, obvious (having no background on the issue and seeing how it was obviously doing the wrong thing, it didn't occur to me that there might be more to it that it seemed at first). Anyway, I don't have sufficient knowledge nor interest in these matters to remain in this discussion (in fact, my slow response time can be attributed to the fact that I don't read gdb-patches very often, I'm significantly behind on it, and I'm not sure when I'm going to have time to even think about catching up on it :-) I suggest the maintainers of this simulator to build a mips-lsi-elf toolchain and attempt to run `make check-gcc' with the simulator to duplicate the problem I had run into, and investigate more closely what the correct fix would be. Thanks, -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer