Baron-von-Riedesel
When tracing a `pushf` instruction with P the apparent TF is not reset on the stack
The T command has a special call to adjust the pushed flags after tracing a pushf instruction, see https://github.com/Baron-von-Riedesel/DOS-debug/blob/b60a75d445f08f9a20abc48ccfb906225194bb41/src/DEBUG.ASM#L6960
It appears this is not called when tracing with the P command, which will in turn result in an apparent TF = 1 result from the pushf instruction.
True, OTOH, this check isn't really fool-proofed ( just opcode 9Ch is checked, but - at least - 66h 9Ch may also push flags ) - so one will probably have to live with occational "unexpected interrupts".
True, OTOH, this check isn't really fool-proofed ( just opcode 9Ch is checked, but - at least - 66h 9Ch may also push flags ) - so one will probably have to live with occational "unexpected interrupts".
True, this is why lDebug skips all prefixes before checking for pushf being traced:
or byte [reg_efl+1], 1 ; set single-step mode (cleared when returning into DEBUG)
xor cx, cx
call skipprefixes
cmp al, 9Ch ; opcode "PUSHF"?
jnz .notpushf
That or instruction is the only point at which lDebug sets the Trace Flag, within the function traceone. This function is also used by the P command (and TP command) if it wants to trace an instruction, instead of calling run directly. So the kitchen sink of trace features are re-used for P.