cgen, GNU gdb/sim, and full system simulation

cgen, GNU gdb/sim, and full system simulation

[Peter Gavin]

Hello,

I'm working on a port of the gdb simulator for OpenRISC.  I was
wondering if anyone had any input on how difficult a full-system
simulator would be to implement vs. the syscall emulated simulators
the other ports seem to use.

The primary thing I'm concerned about at the moment is virtual memory.
 It doesn't look like there's an easy way to add virtual memory to the
simulators.  It would be easy enough to do for load and store
instructions, just by adding a call to an address translation function
prior to accessing the memory.  But it doesn't look like there's a way
to translate the PC prior to fetching an instruction.

I don't mind do a little hacking on the framework, but I don't want to
break things, and I'd like to get some input from you guys before I
start doing that :)

Thanks for your help,
-Pete

Re: cgen, GNU gdb/sim, and full system simulation

[Frank Ch. Eigler]

Hi -

On Fri, May 11, 2012 at 01:57:11PM +0200, Peter Gavin wrote:
> [...]
> I'm working on a port of the gdb simulator for OpenRISC.  I was
> wondering if anyone had any input on how difficult a full-system
> simulator would be to implement vs. the syscall emulated simulators
> the other ports seem to use.

Indeed.  For full-system simulators, some projects have used the sid
framework instead of gdb/sim.

> The primary thing I'm concerned about at the moment is virtual
> memory.  [...]  But it doesn't look like there's a way to translate
> the PC prior to fetching an instruction. [...]

Actually, instruction fetching code can be hand-written in either
gdb-sim (see e.g. sim/m32r/mloop.in extract-*) or sid frameworks
(sid/component/cgen-cpu/m32r/m32rbf.cxx step_insns), and so that code
can map all it likes.

To me, the more interesting question would be the choice to model
virtual memory as a separate component between the CPU and the memory
and I/O buses (which would suite sid's modeling very well), vs
something purely internal to the CPU model.  In either case, the
lookup is only one part: page tables, TLBs, page fault events, all
have to be modeled.

- FChE

Re: cgen, GNU gdb/sim, and full system simulation

[Peter Gavin]

Hi Frank, thanks for the response.

> On Fri, May 11, 2012 at 01:57:11PM +0200, Peter Gavin wrote:
> Indeed.  For full-system simulators, some projects have used the sid
> framework instead of gdb/sim.

Ok.  But we're primarily doing this for GDB, and I suppose gdb can't
use sid, is that right?

> Actually, instruction fetching code can be hand-written in either
> gdb-sim (see e.g. sim/m32r/mloop.in extract-*) or sid frameworks
> (sid/component/cgen-cpu/m32r/m32rbf.cxx step_insns), and so that code
> can map all it likes.

Hmm, I'll look into this.

> To me, the more interesting question would be the choice to model
> virtual memory as a separate component between the CPU and the memory
> and I/O buses (which would suite sid's modeling very well), vs
> something purely internal to the CPU model.

Yeah, I was hoping I could just define a memory in the .cpu file with
define-hardware and have custom get and set methods, but it looks like
that won't work :)

-Pete

Re: cgen, GNU gdb/sim, and full system simulation

[Frank Ch. Eigler]

Hi, Peter -

> Ok.  But we're primarily doing this for GDB, and I suppose gdb can't
> use sid, is that right?

gdb can use sid (via the remote protocol).  Several gdb/toolchain
ports have used sid as the execution backend for e.g. testsuites.

> [...]
> > To me, the more interesting question would be the choice to model
> > virtual memory as a separate component between the CPU and the memory
> > and I/O buses (which would suite sid's modeling very well), vs
> > something purely internal to the CPU model.
> 
> Yeah, I was hoping I could just define a memory in the .cpu file with
> define-hardware and have custom get and set methods, but it looks like
> that won't work :)

Yeah, cgen by itself is not well-suited for modeling such aspects of
the microarchitecture.

- FChE