<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
On 23-Jul-14 14:39, Kevin Handy wrote:<br>
</div>
<blockquote
cite="mid:CANk4W2MiwKZVq9GTuVjn7psqx9vEpLeunMKXS9SEfr6UFGvqwA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>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.<br>
<br>
</div>
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<br>
<br>
</div>
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..<br>
<br>
</div>
</div>
</blockquote>
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... <br>
<br>
The core mission of SimH is to preserve the software that ran on
these machines - other applications are secondary. <br>
<br>
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.<br>
<br>
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.<br>
<br>
For testcase control, what's wrong with expect scripts?<br>
<br>
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...<br>
<br>
Really, external tools are the right way to deal with this.<br>
<br>
<blockquote
cite="mid:CANk4W2MiwKZVq9GTuVjn7psqx9vEpLeunMKXS9SEfr6UFGvqwA@mail.gmail.com"
type="cite">
<div dir="ltr">Just my thoughts on the matter.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jul 23, 2014 at 11:40 AM,
Maciej W. Rozycki <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:macro@linux-mips.org"
target="_blank">macro@linux-mips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On Mon, 21 Jul 2014, Mark Pizzolato - Info
Comm wrote:<br>
<br>
> > I just attended the GNU Tools Cauldron 2014
meeting, where we discussed to<br>
> > use Simh for testing produced code for VAX and
PDP processors. While Simh<br>
> > isn't The Real Thing, it would probably work
quite well.<br>
> ><br>
> > On a first glance, there are some issues
that I'd like to discuss.<br>
> > First of all, a given testcase needs to be
loaded. (Usually, this<br>
> > would be a small binary calling abort() or
returning with zero from<br>
> > main(). We would just supply a fake libc that
sets r0 to zero /<br>
> > nonzero and calls HLT.)<br>
> ><br>
> > Here's the first problem: The PDP11
simulator seems to LOAD a file<br>
> > with kind of a load address -- content ---
load address -- content ...<br>
> > scheme, while the VAX simulator loads a raw
byte. Instead of these<br>
> > ad-hoc formats, our impression is that it
would be nice to have an ELF<br>
> > and/or a.out loader for a static binary.
Either a minimal one, or one<br>
> > using libelf. Would a patch for this be
accepted?<br>
><br>
> Changes which implemented:<br>
> sim> LOAD -A a.out.binaryfile<br>
> and/or<br>
> sim> LOAD -E elf.binaryfile<br>
><br>
> if you do this, then you should consider the
inverse operations as well:<br>
> sim> DUMP -A a.out.binaryfile<br>
> and/or<br>
> sim> DUMP -E elf.binaryfile<br>
><br>
> these would be accepted for the VAX and PDP
simulators as long as it<br>
> worked on all the simh host platforms and therefore
didn't depend on an<br>
> external library. Depending on an external library
would probably be<br>
> extra tricky due to the endian-independent memory
reference model in the<br>
> simulators anyway.<br>
<br>
</div>
</div>
Libelf is widely available, any system that had to do
anything with SVR4<br>
(where this file format has originated from) will have it.
A free<br>
implementation is also available:<br>
<br>
<a moz-do-not-send="true"
href="http://www.mr511.de/software/english.html"
target="_blank">http://www.mr511.de/software/english.html</a><br>
<br>
and the *BSD systems have their replacement too. If your
host doesn't<br>
have a binary readily available (that'd only be more exotic
ones I<br>
suppose, such as MinGW perhaps), then you should be able to
build your<br>
own.<br>
<br>
Libelf is endianness-agnostic and will present ELF file
data structures<br>
in the host endianness regardless of what the endianness of
the file being<br>
processed is, in fact one of the purposes of the library is
to relieve the<br>
app using it from having to byte-swap data explicitly. It's
been a while<br>
since I poked at libelf and I don't remember offhand whether
it does the<br>
swapping thing automatically on opening a file; either way
there are<br>
function calls provided in the API to do that explicitly,
both ways<br>
(file->host & host->file). You need this data in
the host endianness as<br>
you'll be making calculations on them to process the file.
Raw loadable<br>
segments are of course passed unchanged and all DEC
processors are<br>
little-endian I believe so I don't see a problem here.<br>
<br>
Of course you can do without libelf, especially in loading
an executable<br>
only, where what you need to process are only the file
header and the<br>
program headers (the latter providing information about
loadable segments<br>
present in the file), and no such more complicated stuff as
symbols or<br>
relocations. If dumping is implemented, then using the
library will be<br>
especially beneficial, as it'll sort out some of the details
needed to<br>
produce a valid ELF image itself.<br>
<br>
However in my opinion avoiding code duplication has a value
in itself,<br>
starting from <elf.h> that's extensive, and then
including all the<br>
low-level processing stuff. I think writing Yet Another ELF
Loader would<br>
be more appropriate for a bare-iron environment, such as for
a boot loader<br>
included with a console monitor or a piece of firmware of
similar kind,<br>
whereas in a fully-hosted environment it makes sense to use
what the<br>
environment already provides rather than reinventing the
wheel.<br>
<br>
Of course you may disagree and may have arguments against
this approach;<br>
I'd be happy to discuss them.<br>
<div class=""><br>
> > An alternate route could be to put some helper<br>
> > scripts and converter programs together that
build up the proper LOADable<br>
> > files.<br>
><br>
> That could work for you without any adjustments to
simh code. The<br>
> effort should be similar but may leverage other
libraries .<br>
<br>
</div>
The drawback might be some performance loss, depending on
what the<br>
existing interface already provides, e.g. does it handle
gaps in<br>
executables and fill BSS segments itself or do they have to
be loaded as<br>
all-zeros explicitly? This might matter if the simulator
was to be wired<br>
to automatic toolchain testing, as it's already done with
QEMU for<br>
example, where tens of thousands of test cases are loaded in
a sequence<br>
and the download time is one factor. To say nothing of the
overhead of<br>
invoking helper software needed to convert between formats,
e.g.<br>
`objcopy'.<br>
<br>
You need to pass the entry point somehow too; does the
existing interface<br>
do it? In any case that'd have to be extracted from the ELF
executable<br>
somehow, possibly with `readelf' or `objdump', further
postprocessed to<br>
get the value only, that looks like another performance
degradation to me.<br>
<br>
ELF has been designed with easy loading in mind, trying to
avoid mistakes<br>
learnt with earlier executable formats. Therefore I think
it makes sense<br>
to avoid any format conversion and load it directly.<br>
<div class=""><br>
> > A second issue I found is that the remote
telnet port isn't serviced<br>
> > unless the simulator is actually running. It
would be quite cool to<br>
> > expose it's capabilities even earlier: The final
intention is to<br>
> > interface it with GDB as a debugger. In this
setup, GDB would see Simh<br>
> > as something like a "probe" or "accessor" to a
(real) VAX system, like<br>
> > remote debugging for some other development
boards is done today.<br>
><br>
> One of the envisioned goals of the existing REMOTE
CONSOLE support was<br>
> to facilitate a generic means of possibly
implementing simulator<br>
> specific blinken-lights front panels. GDB could
certainly be considered<br>
> a case in this domain.<br>
><br>
> The use of a simulator in such a way would certainly
require specific<br>
> setup conditions for it to work at all. If GDB was
really going to be<br>
> the driving force the simulator startup would have to
be configured to<br>
> support this and several other
accommodations/extended behaviors would<br>
> probably be necessary (handling simh break point
processing via a remote<br>
> console quickly comes to mind). We can explore this
and other details<br>
> if you want to move down that path.<br>
<br>
</div>
For GDB control a Remote Serial Protocol aka RSP stub will
have to be<br>
implemented. At the very minimum it'll have to support
commands (called<br>
packets in RSP-speak) to peek and poke at target registers
and memory, and<br>
to execute, single-step, interrupt execution, and to set and
remove<br>
breakpoints (GDB can set software breakpoints itself by
patching code with<br>
whatever instruction is used by the architecture, but with a
bare-iron<br>
target such as a simulator is that'd have to be an ICE/JTAG
kind of a<br>
breakpoint instruction rather than a user breakpoint
instruction, such as<br>
BPT in the case of the VAX processor, that has to be left
alone for use by<br>
software run within the simulator rather than for use by the
simulator<br>
itself).<br>
<span class="HOEnZb"><font color="#888888"><br>
Maciej<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
_______________________________________________<br>
Simh mailing list<br>
<a moz-do-not-send="true"
href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a moz-do-not-send="true"
href="http://mailman.trailing-edge.com/mailman/listinfo/simh"
target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Simh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></pre>
</blockquote>
<br>
</body>
</html>