[Simh] Simh for testsuite usage

[Mark Pizzolato - Info Comm]

On Sunday, July 20, 2014 at 5:12 PM, Jan-Benedict Glaw wrote:
> I just attended the GNU Tools Cauldron 2014 meeting, where we discussed to
> use Simh for testing produced code for VAX and PDP processors. While Simh
> isn't The Real Thing, it would probably work quite well.
> 
>   On a first glance, there are some issues that I'd like to discuss.
> First of all, a given testcase needs to be loaded. (Usually, this would be a small
> binary calling abort() or returning with zero from main(). We would just
> supply a fake libc that sets r0 to zero / nonzero and calls HLT.)
> 
>   Here's the first problem: The PDP11 simulator seems to LOAD a file with
> kind of a load address -- content --- load address -- content ...
> scheme, while the VAX simulator loads a raw byte. Instead of these ad-hoc
> formats, our impression is that it would be nice to have an ELF and/or a.out
> loader for a static binary. Either a minimal one, or one using libelf. Would a
> patch for this be accepted?  

Changes which implemented:
	sim> LOAD -A a.out.binaryfile
and/or
	sim> LOAD -E elf.binaryfile

if you do this, then you should consider the inverse operations as well:
	sim> DUMP -A a.out.binaryfile
and/or
	sim> DUMP -E elf.binaryfile

these would be accepted for the VAX and PDP simulators as long as it worked on all the simh host platforms and therefore didn't depend on an external library.  Depending on an external library would probably be extra tricky due to the endian-independent  memory reference model in the simulators anyway.

The license should be consistent with the standard language which is at the header of scp.c, etc.

> An alternate route could be to put some helper
> scripts and converter programs together that build up the proper LOADable
> files.

That could work for you without any adjustments to simh code.  The effort should be similar but may leverage other libraries .

>   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.

- Mark