From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12070 invoked by alias); 24 Apr 2002 18:19:18 -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 11992 invoked from network); 24 Apr 2002 18:18:58 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 24 Apr 2002 18:18:58 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 24 Apr 2002 11:18:30 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-2.sj.broadcom.com (mail-sj1-2 [10.16.128.232]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g3OIIv1S022131; Wed, 24 Apr 2002 11:18:57 -0700 (PDT) Received: (from cgd@localhost) by mail-sj1-2.sj.broadcom.com ( 8.9.1/SJ8.9.1) id LAA20545; Wed, 24 Apr 2002 11:18:57 -0700 (PDT) To: aoliva@redhat.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: cgd@broadcom.com Date: Wed, 24 Apr 2002 11:19:00 -0000 In-Reply-To: aoliva@redhat.com's message of "Wed, 24 Apr 2002 01:24:20 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 10D8297C637810-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00958.txt.bz2 At Wed, 24 Apr 2002 01:24:20 +0000 (UTC), "Alexandre Oliva" wrote: > > * 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. Uh, not true AFAICT. The LSIPMON handler pointers for which this might be a problem are the ones when loop == 0 and loop == 1, right? Since both of those are written, really, there would be no "half halt sequences" remaining. > 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. "hmm." > 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. That's unfortunate. I'd certainly be willing, as co-maintainer, to help look into the problem. However, my time is rather limited. The first thing to do there is IMO probably _not_ to run the GCC tests; you've already verified that they're borken. It's to find out exactly what LSIPMON is _supposed_ to be doing, and why. (The theory being that it's important to understand what you're trying to change, before you go and change it. 8-) I think that's the most sane path to a fix that's likely to work in the longer term. Do (any of) you have pointers to documentation which will help elucidate LSIPMON's use of 0xbfc00200? cgd