[Simh] Simh for testsuite usage
Maciej W. Rozycki
macro at linux-mips.org
Wed Jul 23 13:40:32 EDT 2014
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
More information about the Simh
mailing list