From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29555 invoked by alias); 19 Apr 2002 22:32:35 -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 29482 invoked from network); 19 Apr 2002 22:32:30 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 19 Apr 2002 22:32:30 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Fri, 19 Apr 2002 15:32:26 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 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 g3JMWT1S007350; Fri, 19 Apr 2002 15:32:29 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id PAA14034; Fri, 19 Apr 2002 15:32:28 -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: Fri, 19 Apr 2002 15:32:00 -0000 In-Reply-To: "Alexandre Oliva"'s message of "19 Apr 2002 18:06:34 -0300" Message-ID: MIME-Version: 1.0 X-WSS-ID: 10DE457034668-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00640.txt.bz2 At 19 Apr 2002 18:06:34 -0300, Alexandre Oliva wrote: > Ok, so could you please explain to me how these two chunks of code can > possibly be correct: > > if (lsipmon_monitor_base != 0) > { > address_word vaddr = (lsipmon_monitor_base + (loop * 4)); > sim_write (sd, vaddr, (char *)&value, sizeof (value)); > } > > (where lsipmon_monitor_base is 0xBFC00200, and loop varies from 0 to > 23. I read that as writing pointers into lsipmon_monitor_base) > > sim_write (sd, 0xBFC00200, (char *) halt, sizeof (halt)); > sim_write (sd, 0xBFC00380, (char *) halt, sizeof (halt)); > sim_write (sd, 0xBFC00400, (char *) halt, sizeof (halt)); > > (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'? (64 bit or 64-byte, I don't see what you mean by 'overwrites its own entry...') I think it's clear -- otherwise you wouldn't have had a problem to begin with -- that the current situation doesn't do what's intended for lsipmon. 8-) More towards the bottom... 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. 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. > > I cannot believe that any monitor does what you describe (puts a table > > of addresses here), as doing so (instead of putting vectors there) > > would be fundamentally incompatible with the MIPS architecture. > > I stand corrected. It doesn't write pointers into chose chunks. I > misremembered what I had seen. The values of `value' that are written > in the first chunk of code as numbers that range from 6 to 28, except > for the printf service. However, I don't see how a code sequence that > halts the machine could possibly fit there as an entry in the vector > table. So, you get to these vectors via exceptions (e.g., TLB exceptions, address errors, etc.) The action that the 'halt'-writing code accomplishes is that it arranges to halt the simulator when you get one of these exceptions. That seems like a reasonable thing to do. What I believe you want to do here is: * 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-) chris