When tracing a `pushf` instruction with P the apparent TF is not reset on the stack

[ecm-pushbx]

The T command has a special call to adjust the pushed flags after tracing a pushf instruction, see

DOS-debug/src/DEBUG.ASM

Line 6960 in b60a75d

call clear_tf_onstack

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.

[Baron-von-Riedesel]

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".

[ecm-pushbx]

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.