screen flip with binw\wd debugger v1.9

[japheth]

the screen "flip" feature, which is the default setting for binw\wd, seems not
to work in OW 1.9. It neither works in NTVDM nor in true DOS.

I have a vague idea of how certain parts of WD work ( I made a trap file 6
years ago ) and hence found a suspicious location in file dbgexec.c, function
ExecProg():

case MTRH_SIMULATE:
case MTRH_STEP:
case MTRH_STEPBREAK:
if( _IsOff( SW_TOUCH_SCREEN_BUFF ) ) break;
/* fall through */
default:

If the "if( _IsOff( SW_TOUCH_SCREEN_BUFF ..." line is commented out, screen
flipping works again - but there may be "unknown" side effects. I was unable
to find any comment or documentation what switch SW_TOUCH_SCREEN_BUFF is
supposed to do. Does anybody know?

[Hans-Bernhard Bröker]

Post by japheth
the screen "flip" feature, which is the default setting for binw\wd,
seems not to work in OW 1.9.

May be you should expand on "seems not to work" a bit. That's rather
vague. What exactly did you expect, in what situation, and what
happened instead?

And since you explicitly mention OW 1.9: do you have any idea if this
used to work in earlier versions, and if so, when?

Post by japheth
I have a vague idea of how certain parts of WD work ( I made a trap file
6 years ago ) and hence found a suspicious location in file dbgexec.c,
if( _IsOff( SW_TOUCH_SCREEN_BUFF ) ) break;
/* fall through */

I don't quite agree. This doesn't look suspicious at all. In
particular, removing that condition would appear to be unwise. It would
trigger the flip in several situations (note the MTRH_STEP and
_STEPBREAK in the snippet above) where it would be wrong to do that.
You would get a flip on every step.

Post by japheth
was unable to find any comment or documentation what switch
SW_TOUCH_SCREEN_BUFF is supposed to do. Does anybody know?

In the absence of comments it pays to dig a bit deeper into the source
code itself. The next steps in that chain are:

*) directly above the quoted material, SW_TOUCH_SCREEN_BUF is set if
trace mode is BREAK. I.e. you would always get a flip when you just hit
a breakpoint, but not during normal stepping or simulation. Seems sensible.

*) wv/c/madinter.c:MADCliNotify():199 sets flag SW_TOUCH_SCREEN_BUFF if
something calls it with argument MNT_EXECUTE_TOUCH_SCREEN_BUF.

*) That call comes from mad/c/madimp.c:MCNotify(), which in turn is
called with argument MNT_EXECUTE_TOUCH_SCREEN_BUF in one place only:
mad/x86/c/x86trace.c:TouchesScreenBuff(). That function tries to detect
if the debuggee is about to manipulate the screen during debugging, by
checking the address being workd on. If so, it will trigger the flip.

*) All of the functions that turned up during this drilling have never
been changed (setting aside code layout) since OW was first checked in.
So if this is broken now, I would appear it must have been so since
before OpenWatcom started.

*) The only change that happened near this chain of events is changelist
36826: the implementation of optional asynchronous debugging. That
placed some modifications near the place in dbgexec.c you found. So if
there's anything to be suspicious about here, it would be that change.

[japheth]

May be you should expand on "seems not to work" a bit. That's rather vague.

Yes. I expect that - in a single screen system, with screen flipping on
(/PAGE) and option "Screen flip on execution" also set - the text-mode
debuggee's output goes to the application's screen, not to the debugger's
screen - even if I use F8 (trace into) to proceed and not F10 (step over).

Why? Because AFAICS there is no warning in the documentation ( or even
mentioned at all ) that the trace command must be used carefully, else output
would be "lost". There is a warning about graphics mode applications having to
use /SWAP, but this obviously doesn't apply in this case.

[japheth]

I don't quite agree. This doesn't look suspicious at all. In particular,
removing that condition would appear to be unwise. It would trigger the flip
in several situations (note the MTRH_STEP and _STEPBREAK in the snippet above)
where it would be wrong to do that. You would get a flip on every step.

Well, yes, but that wouldn't be that bad - at least not if /PAGE is set.

*) directly above the quoted material, SW_TOUCH_SCREEN_BUF is set if trace
mode is BREAK. I.e. you would always get a flip when you just hit a
breakpoint, but not during normal stepping or simulation. Seems sensible.

IMO that's a bit too "aggressive".

*) That call comes from mad/c/madimp.c:MCNotify(), which in turn is called
mad/x86/c/x86trace.c:TouchesScreenBuff(). That function tries to detect if the
debuggee is about to manipulate the screen during debugging, by checking the
address being workd on. If so, it will trigger the flip.

Ok, thanks! The TouchesScreenBuff() function seems overly simple IMO. However,
file x86trace.c does indeed offer a location to make the screen switch more
conditional. In function CheckSpecial(), case DI_X86_int:

switch( dd->ins.type ) {
case DI_X86_int:
MCNotify( MNT_EXECUTE_TOUCH_SCREEN_BUFF, NULL ); /* added */
if( dd->ins.flags & DIF_X86_EMU_INT )
break;
/* fall through */
case DI_X86_into:
if( !( dd->characteristics & X86AC_REAL ) )
break;
return( MTRH_SIMULATE );

Now the screen flip is triggered only if an INT is to be "traced". That's at
least an improvement.

I suggest this one-line modification to be implemented in the standard version.

[Marty Stanquist]

Have you tried making the change? Does it work as expected?

Marty

I don't quite agree. This doesn't look suspicious at all. In particular,
removing that condition would appear to be unwise. It would trigger the flip
in several situations (note the MTRH_STEP and _STEPBREAK in the snippet above)
where it would be wrong to do that. You would get a flip on every step.

Well, yes, but that wouldn't be that bad - at least not if /PAGE is set.

*) directly above the quoted material, SW_TOUCH_SCREEN_BUF is set if trace
mode is BREAK. I.e. you would always get a flip when you just hit a
breakpoint, but not during normal stepping or simulation. Seems sensible.

IMO that's a bit too "aggressive".

*) That call comes from mad/c/madimp.c:MCNotify(), which in turn is called
mad/x86/c/x86trace.c:TouchesScreenBuff(). That function tries to detect if the
debuggee is about to manipulate the screen during debugging, by checking the
address being workd on. If so, it will trigger the flip.

Ok, thanks! The TouchesScreenBuff() function seems overly simple IMO.
However,
file x86trace.c does indeed offer a location to make the screen switch more
conditional. In function CheckSpecial(), case DI_X86_int:

switch( dd->ins.type ) {
case DI_X86_int:
MCNotify( MNT_EXECUTE_TOUCH_SCREEN_BUFF, NULL ); /* added */
if( dd->ins.flags & DIF_X86_EMU_INT )
break;
/* fall through */
case DI_X86_into:
if( !( dd->characteristics & X86AC_REAL ) )
break;
return( MTRH_SIMULATE );

Now the screen flip is triggered only if an INT is to be "traced". That's at
least an improvement.

I suggest this one-line modification to be implemented in the standard
version.

[japheth]

Post by Marty Stanquist
Have you tried making the change? Does it work as expected?

Yes.

But please don't feel pressed to add the proposed fix! The fact that I
"recommend" it's implementation doesn't mean too much. If there's nobody on
the "maintainer crew" side who's capable - or has the time - to say: yes, it's
a bug and the fix has no unwanted side effects - then it's obviously very
reasonable to IGNORE the proposal.

I also want to mention that I didn't claim that it's a regression. I told that
it occured in v1.9, but that's just what it is: as additional information.
Most likely the bug existed since OW exists - or even longer - and nobody
cared. There are quite a few other things that I regard as bug ( for example,
that the STD.TRP file doesn't allow to view or edit the true contents of the
XMM registers or that the interrupt flag is cleared when the debuggee starts )
but which are obviously so minor to virtually all users that they exist since
at least 12 years.

[Leif Ekblad]

I cannot confirm if this is broken on DOS or NTVMD, but at least it works in
a DOS-box in Windows XP. It also works in RDOS. However, all those
environments use process-switching rather than saving screen buffer, so real
screen buffer flipping might still be broken. The switching logic seems to
be correct though.

On 13.12.2012 19:49, japheth wrote: *) The only change that happened near
this chain of events is changelist 36826: the implementation of optional
asynchronous debugging. That placed some modifications near the place in
dbgexec.c you found. So if there's anything to be suspicious about here,
it would be that change.

AFAIK, that particular change should not have broken screen-flip logic.
OTOH, I'm not sure that this is the correct place to look for it either.
There were a few other changes when implementing asynchronous debugging, but
I (hope) none of those broke anything. Since it appears that switching is
done when it should, I would look at the particular logic for saving &
restoring screen buffer.

It would be interesting to see when exactly it was broken. I think there is
a need to find this out.

Leif Ekblad

[Marty Stanquist]

I agree also. I'll start looking into it.

Marty

"Leif Ekblad" wrote in message news:kaknlr$3el$***@www.openwatcom.org...

I cannot confirm if this is broken on DOS or NTVMD, but at least it works in
a DOS-box in Windows XP. It also works in RDOS. However, all those
environments use process-switching rather than saving screen buffer, so real
screen buffer flipping might still be broken. The switching logic seems to
be correct though.

On 13.12.2012 19:49, japheth wrote: *) The only change that happened near
this chain of events is changelist 36826: the implementation of optional
asynchronous debugging. That placed some modifications near the place in
dbgexec.c you found. So if there's anything to be suspicious about here,
it would be that change.

AFAIK, that particular change should not have broken screen-flip logic.
OTOH, I'm not sure that this is the correct place to look for it either.
There were a few other changes when implementing asynchronous debugging, but
I (hope) none of those broke anything. Since it appears that switching is
done when it should, I would look at the particular logic for saving &
restoring screen buffer.

It would be interesting to see when exactly it was broken. I think there is
a need to find this out.

Leif Ekblad