> disassemble _one byte_ without extreme prejudice. Mark's solution really
^^^^^^^^^^^^^^^
hmm, I obviously missed this information.
Could you please FWD it to me ? (private mail)
> seems to be the most robust one, with the small extension that 'trap #1'
^^^^^^^
> (hw debug trap) _has_ to point to after the trapping instruction as well
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, this doesn't hurt us atall: you need _not_ to fixup eip for that
(hence interpretation of the code isn't necessary), because:
The trap #1 can be triggered for the following cases:
- Instruction breakpoint fault (DRx caused)
without F00F-fix: pointing _to_ the instruction.
_with_ F00F-fix: dito
What we should eventually fiddle with is just the RF flag,
but as the processor does the handling of this on _return_ of
of the exception, we have not to handle this _before_ calling
do_debug().
- Data memory and I/O breakpoints (DRx caused)
without F00F-fix: pointing _after_ the instruction, that caused
the exception.
_with_ F00F-fix: The exception is scheduled _after_ the instruction
and therefore the page fault too (fortunately).
hence: just what we need, no fixup needed.
- General detect fault (DRx caused)
We can skip that, because its only used in conjunction with
in-circuit emulators.
- Singe step trap (the 'classic' INT1)
In both cases (with or without the F00F fix) the exception happens
_after_ the instruction that was executed with TF set in eflags.
Hence no fixup needed.
- Task switch trap. ( caused by T-bit in the TSS )
Along my knowledge of the kernel, this won't happen, because we are
not using machine type taskswitches to switch context
(correct me if I'm wrong). Atleast, I did not find the places in the
kernel were we fiddle with the T bit of the TSS (Linus ?).
... and we should, if this is of concern.
Hans
<lermen@fgan.de>