[Simh] Simh for testsuite usage

[Mark Pizzolato - Info Comm]

On Thursday, July 24, 2014 at 4:11 PM, Mark Pizzolato wrote:
> On Wednesday, July 23, 2014 at 10:41 AM, Maciej W. Rozycki wrote:
> > On Mon, 21 Jul 2014, Mark Pizzolato - Info Comm wrote:
> >
> > > >   A second issue I found is that the remote telnet port isn't
> > > > serviced unless the simulator is actually running. It would be
> > > > quite cool to expose it's capabilities even earlier: The final
> > > > intention is to interface it with GDB as a debugger. In this
> > > > setup, GDB would see Simh as something like a "probe" or
> > > > "accessor" to a (real) VAX system, like remote debugging for some
> > > > other development boards is
> > done today.
> > >
> > > One of the envisioned goals of the existing REMOTE CONSOLE support
> > > was to facilitate a generic means of possibly implementing simulator
> > > specific blinken-lights front panels.  GDB could certainly be
> > > considered a case in this domain.
> > >
> > > The use of a simulator in such a way would certainly require
> > > specific setup conditions for it to work at all.  If GDB was really
> > > going to be the driving force the simulator startup would have to be
> > > configured to support this and several other accommodations/extended
> > > behaviors would probably be necessary (handling simh break point
> > > processing via a remote console quickly comes to mind).  We can
> > > explore this and other details if you want to move down that path.
> >
> >  For GDB control a Remote Serial Protocol aka RSP stub will have to be
> > implemented.  At the very minimum it'll have to support commands
> > (called packets in RSP-speak) to peek and poke at target registers and
> > memory, and to execute, single-step, interrupt execution, and to set
> > and remove breakpoints (GDB can set software breakpoints itself by
> > patching code with whatever instruction is used by the architecture,
> > but with a bare-iron target such as a simulator is that'd have to be
> > an ICE/JTAG kind of a breakpoint instruction rather than a user
> > breakpoint instruction, such as BPT in the case of the VAX processor,
> > that has to be left alone for use by software run within the simulator rather
> than for use by the simulator itself).
> 
> This is good information.
> 
> I've reviewed what this involves and the current simh REMOTE CONSOLE
> capabilities do need some extension to support the minimal set of abilities
> that a GDB RSP stub would require.  I'll look at working on these changes so
> that someone else can tackle the actual implementation of the RSP stub(s)
> for each of the respective VAX and PDP11 simulators if they desire (the
> implementation would leverage a TCP circuit to a simh REMOTE CONSOLE).
> 
> Any use of a simh simulator in a test framework will require any number of
> test related configuration steps to initiate the simulator to serve this
> purpose.  Invoking external elf/a.out transformation tools as part of those
> configuration steps should be relatively trivial.   So, as a starting point I would
> think that external tools would be a sufficient solution to the problem.  Once
> those details have been worked out, if the external tools are a prohibitive
> bottleneck to the problem alternate approaches can be explored.
> 
> If someone wants to implement a simh GDB RSP stub, please create an issue
> at https://github.com/simh/simh/issues to track this activity and work out
> any integration/implementation details.

The necessary extensions to the existing simh Remote Console capabilities now exist so that someone can implement an external process which is the GDB RSP stub and handle all of the necessary behaviors.

The simh facility to support this is enabled by:
 
      sim> set remote telnet=port
      sim> set console telnet=consoleport
      sim> set remote master

>From that point on, all simh commands to initiate, halt, step, examine the running simulator are available through a TCP session on 'port'.

- Mark