This problem only appears when debug output is prodigious. That
prodigious activity is already dramatically affecting timing, so adding
additional delays to allow the debug output to catch up won't
make anything worse.
It appears that we could jump over the C runtime implementation of
fwrite() and do an explicit write() system call and retry that until it
succeeds, but this approach would have two negative consequences:
1) it would jump over other buffered data that the C runtime fwrite()
may have pending due to output produced by other than debug
activities, thus emitting output out of order.
2) Windows doesn't have a direct system call used by its C runtime
for write(), but merely implements write() as part of the C runtime
and as it turns out that write() returns an int vs a ssize_t type
result. An explicit cast could address this, but point 1 would still
be a concern.
As discussed in #957
Previously, the status returned by fwrite() while writing debug output
was ignored and all debug output was presumed to be correctly written.
This change tolerates incomplete writes performed by the C runtime
and retries the remaining writes as long as the retries take.
This change completely presumes that the C runtime fwrite() returns
correct information when the data has not been completely written.
That of course will likely depend on the OS level write function
returning correct informatoin from the write() system call that
fwrite() depends on.
Timing concerns while emitting debug output have always been a
problem since even composing any debug output is likely to be much
more work than basic instruction execution off the current single
instruction. Clock calibration probably will be fundamentally unreliable.
As discussed in #957
- When sim_interval is negative (vs 0), more "time" has passed than
when the first unit event on the queue was supposed to fire. To
properly handle this and dispatch this and other events which should
have fired, time is temporarily backed up to when it was supposed
to have fired and the event is dispatched. If it schedules other
events those will then properly be scheduled relative to the time is
has fired. This approach avoids events slipping forward in time.
- Add unit test to exercise event dispatching activities.
The OS may signal SIGTERM more than once before ultimately
issuing a SIGKILL. The initial SIGTERM will stop execution and
initiate optional simulator cleanup. Ignoring follow up SIGTERMs
will allow as much cleanup as possible to be achieved and thus
allow the simulator to complete its cleanup and exit or ultimately
exit die due to receipt of SIGKILL.
Likewise for SIGHUP on hosts that can issue SIGHUP.
The paradigm of using a "weak" linker reference to find what was
previously the vm_init_routine() doesn't work reliably on all compile
environments supported by the simulators. This has been reported
in #794 and it came up again in #862. This change assures that
it will not come up again AND it reliably solves the problem with
Visual Studio compilers (and linker) that randomly chooses whether
to have the desired effect or not.
Of the 82 simulators which are currently part of simh, only these
three used the sim_vm_init() interface, so removing it had relatively
minor impact.
This allowed user entered S to match the SAMPLEOUT command instead
of STEP. That then identified a bug in the intended socket output
processing to attempt to be written to the undefined debug file.
As discussed in #854
Previously, numeric values incorrectly had a string representation of
"". This allowed arbitrary equality comparisons to succeed in unexpected
ways.
Reported by Robert Sancho Villas
- Previously invoking a simulator with -T was the only way to invoke the
library tests for ALL devices. That still works now with the additional
flexibility to invoke a specific device's test from the sim> prompt.
- Adding TESTLIB help text encountered a maximum constant string length
limit in the C compiler. Reworked to allow multiple strings which are then
concatenated on the first HELP command invocation.
