This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS simulator initializes LSI pmon vector table with code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]