[ #433759 ] virtual address checks can overflow
> Bochs has been crashing in some cases when you try to access data which
> overlaps the segment limit, when the segment limit is near the 32-bit
> boundary. The example that came up a few times is reading/writing 4 bytes
> starting at 0xffffffff when the segment limit was 0xffffffff. The
> condition used to compare offset+length-1 with the limit, but
> offset+length-1 was overflowing so the comparison went wrong. This patch
> changes the condition so that it supports all segment limits except for
> sizes 0,1,2,3 bytes. Dave and I figured that these sizes would not be
> needed, while size 0xffffffff is used quite a lot.
I still need to do add some commands from older specs that are obsolete
(and not listed) in ATAPI-6.
- commands that aren't in the spec will still panic.
- fill in names from spec on various commands
- add command aborted for 0x08 device reset on disks (it's only for ATAPI)
- add command aborted for 0xe1 idle immediate
media status to 0 then 1 (equivalent to removing then inserting a disk).
Then it calls the UI function bx_gui.update_floppy_status_buttons()
if the interface has been initialized already.
has run. This ensures that the prev_eip and prev_esp that is used
for tracing and breakpoint checks is correct even in the cycle after
an interrupt or trap.
in performance, but I did not check the debugger carefully enough while
testing them. Part of the performance gain in main.cc revision 1.33 and
cpu.cc revision 1.9 was to allow bochs to stay in the cpu loop forever
in a single processor simulation. (In a multiprocessor simulation it must
quit the loop periodically to give the other procs a chance to simulate
too. Cooperative multiprocessing?) In the process, I restored calls
to BX_TICK in the cpu loop for 1-proc simulation only, and removed them
from the outer loop. (See main.cc, since it was done right.) However
I never made the equivalent change in the debugger code, so in the
debugger, there were ticks coming from the cpu loop and then an
equivalent number of ticks coming from the debugger code just outside
the cpu loop. The result was, of course, that simulation time went
at 2x the correct rate. This simulation time speedup was made even
worse because the continue loop in the debugger would increment ticks
by one quantum (5 at the time) no matter how many instructions had
actually been executed. So in trace mode in particular, the way it was
implemented before today, cpu loop would run only one instruction at
a time and the simulation time would get incremented 1+5=6 times! One
tick from the cpu loop, then 5 erroneous ticks from the continue loop.
Anyway, much of this nonsense should be fixed now. For uniprocessor
simulations, only the cpu loop does ticks (for best performance). For
multiprocessor simulations, the cpu loop exits after one quantum and
the code that calls the cpu loop gets to increment ticks instead.
> This patch fixes a number of debugger problems.
> - with trace-on, simulation time would pass 5x faster than usual, so
> interrupts and other timed events would happen at different times
> - with trace-on, breakpoints were ignored
> - with trace-on, control-C would not stop the processor and return to the
> debugger.
>
> This patch changes the execution quantum for the debugger to 1, which means
> that cpu_loop is asked to do one instruction at a time. This may cause
> bochs with the debugger to be slower than before.
>
> I haven't tested without the debugger yet, so I don't know if the timing
> of events matches or not.
