From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30959 invoked by alias); 22 Apr 2002 19:09:04 -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 30943 invoked from network); 22 Apr 2002 19:09:03 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 22 Apr 2002 19:09:03 -0000 Received: from free.redhat.lsd.ic.unicamp.br (vpn3-1.sfbay.redhat.com [172.16.25.1] (may be forged)) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g3MJ8Vv15899; Mon, 22 Apr 2002 12:08:31 -0700 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g3MJ8sw16424; Mon, 22 Apr 2002 16:08:54 -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: Mon, 22 Apr 2002 12:09: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/msg00804.txt.bz2 On Apr 19, 2002, cgd@broadcom.com wrote: >> (where halt is 64-byte long chunk of code, which means that one of >> these halts overwrites not only its own entry in lsipmon_monitor_base, >> but also the following entry.) > Together, you mean? And I assume you mean 64-bit rather than > '64-byte'? Yes, sorry. > (64 bit or 64-byte, I don't see what you mean by 'overwrites its own > entry...') I mean that the entry is supposed to contain a vector number or something, like what we write in there in the loop above, but the way the code is written, we get code into it, that doesn't even fit in a single entry. This is blatantly, obviously wrong. > Well, note that I'm not the author of this code, nor was I a > maintainer when it got into its current state. I suggest you look at > the diffs between rev 1.1 and 1.2 -- and then consult fche, who made > the change -- to find out why those changes were made. 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 :-( > 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. 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, you get to these vectors via exceptions (e.g., TLB exceptions, > address errors, etc.) Except that the meaning of the vector varies from one monitor to the other. While some expect to find code there, others expect addresses. > 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. In the case of lsipmon, not only does it change the entry corresponding to an uninitialized service, but also the following one, that happens to be a useful one, and one that had been initialized correctly, just to have the correct value overwritten by the second half of a halt sequence. > * do the writes to the vector table first, iff you're using any of the > monitors. > * then do the additional writes as-is if you're using pmon or lsipmon > as the monitor. > This has the somewhat odd effect that if you're using lsipmon, the BEV > TLB Miss vector doesn't halt the simulator... but for all I know, the > CPUs you're talking about & for which you'd use 'lsipmon' had no TLBs > or something so that point would be moot. 8-) The right thing to do is to not write code into the table if it's not supposed to contain code. If anything, one might want to get it to somehow point at code elsewhere in the monitor address space that would halt the machine. But writing code there on all monitors can't be right if some monitors don't take code in there. -- 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