[Simh] Simh for testsuite usage
Timothe Litt
litt at ieee.org
Wed Jul 23 15:03:44 EDT 2014
On 23-Jul-14 14:39, Kevin Handy wrote:
> 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..
>
I agree. The SimH loaders are designed to load the native format
bootstraps. Getting ELF right is out of scope for SimH - first, because
it isn't portable (SimH runs on VMS, Windows and other environments that
don't have libelf). Second, because to do it right, you have to handle
shared libraries and deal with the fact that memory management is OFF -
as may also be traps and exception handling in the emulated machine. I
know the current request was for 'a static binary', but the next request
(probably from someone else) will be to enhance it...
The core mission of SimH is to preserve the software that ran on these
machines - other applications are secondary.
This request really is application specific and should be done as
external utilities. This is much simpler, as you need only make the
utilities work in your testcase development environment.
I'm fine with using SimH as a reference machine, although it is designed
to emulate implementations, not architectures. That is, it is
bug-for-bug compatible with, e.g. VAX models, but does not implement the
VAX architecture of the SRM.
For testcase control, what's wrong with expect scripts?
If you insist on developing these patches, at least make sure that they
are conditionally compiled OFF by default with as much of the code as
possible in separate sourcefiles. And be sure that you are willing to
sign up to maintain them, long after your current project ends...
Really, external tools are the right way to deal with this.
> Just my thoughts on the matter.
>
>
> On Wed, Jul 23, 2014 at 11:40 AM, Maciej W. Rozycki
> <macro at linux-mips.org <mailto: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 <mailto:Simh at trailing-edge.com>
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> 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/23fbeada/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140723/23fbeada/attachment-0002.bin>
More information about the Simh
mailing list