[Simh] Simh for testsuite usage

Wed Jul 23 14:39:55 EDT 2014

I think that adding all of this complexity to simh to handle one load type
might be a bit overkill. After adding elf support, you will probably need
to add VMS, RT11, RSX, etc... support.

I think that it would be better to create external utilities that would
convert the onject format to a simpler format that "load" understands. If
you then had simh call that utility a part of a "load" command (popen?) you
would be able to create any number of loaders with little increase in the
complexity and size of simh. It would also make the utilities availabe
outside of simh itself. It would probably also be much simpler to debug

Tools like this might be of interest to others outside of simh. For
example, someone might want to be able to load an elf binary on real
hardware without an OS..

Just my thoughts on the matter.

On Wed, Jul 23, 2014 at 11:40 AM, Maciej W. Rozycki <macro at linux-mips.org>
wrote:

> On Mon, 21 Jul 2014, Mark Pizzolato - Info Comm 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.
>
>  Libelf is widely available, any system that had to do anything with SVR4
> (where this file format has originated from) will have it.  A free
> implementation is also available:
>
> http://www.mr511.de/software/english.html
>
> and the *BSD systems have their replacement too.  If your host doesn't
> have a binary readily available (that'd only be more exotic ones I
> suppose, such as MinGW perhaps), then you should be able to build your
> own.
>
>  Libelf is endianness-agnostic and will present ELF file data structures
> in the host endianness regardless of what the endianness of the file being
> processed is, in fact one of the purposes of the library is to relieve the
> app using it from having to byte-swap data explicitly.  It's been a while
> since I poked at libelf and I don't remember offhand whether it does the
> swapping thing automatically on opening a file; either way there are
> function calls provided in the API to do that explicitly, both ways
> (file->host & host->file).  You need this data in the host endianness as
> you'll be making calculations on them to process the file.  Raw loadable
> segments are of course passed unchanged and all DEC processors are
> little-endian I believe so I don't see a problem here.
>
>  Of course you can do without libelf, especially in loading an executable
> only, where what you need to process are only the file header and the
> program headers (the latter providing information about loadable segments
> present in the file), and no such more complicated stuff as symbols or
> relocations.  If dumping is implemented, then using the library will be
> especially beneficial, as it'll sort out some of the details needed to
> produce a valid ELF image itself.
>
>  However in my opinion avoiding code duplication has a value in itself,
> starting from <elf.h> that's extensive, and then including all the
> low-level processing stuff.  I think writing Yet Another ELF Loader would
> be more appropriate for a bare-iron environment, such as for a boot loader
> included with a console monitor or a piece of firmware of similar kind,
> whereas in a fully-hosted environment it makes sense to use what the
> environment already provides rather than reinventing the wheel.
>
>  Of course you may disagree and may have arguments against this approach;
> I'd be happy to discuss them.
>
> > > 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 .
>
>  The drawback might be some performance loss, depending on what the
> existing interface already provides, e.g. does it handle gaps in
> executables and fill BSS segments itself or do they have to be loaded as
> all-zeros explicitly?  This might matter if the simulator was to be wired
> to automatic toolchain testing, as it's already done with QEMU for
> example, where tens of thousands of test cases are loaded in a sequence
> and the download time is one factor.  To say nothing of the overhead of
> invoking helper software needed to convert between formats, e.g.
> `objcopy'.
>
>  You need to pass the entry point somehow too; does the existing interface
> do it?  In any case that'd have to be extracted from the ELF executable
> somehow, possibly with `readelf' or `objdump', further postprocessed to
> get the value only, that looks like another performance degradation to me.
>
>  ELF has been designed with easy loading in mind, trying to avoid mistakes
> learnt with earlier executable formats.  Therefore I think it makes sense
> to avoid any format conversion and load it directly.
>
> > >   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).
>
>   Maciej
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140723/2ac95e70/attachment-0002.html>