Page 3 of 3

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Tue Feb 06, 2018 7:28 am
by Ivan Denisov
Checked with Windows 10 and Wine-3.0

Published
https://blackbox.obertone.ru/component/RemDebug
I used X512 version and ideas of Josef. That is why I added you to the authors.

works with
https://blackbox.obertone.ru/unstable/m ... a1.053.zip
The Kernel was patched with one procedure for integer to string conversion and several lines in the Init procedure.

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Thu Feb 15, 2018 9:06 am
by Josef Templ
Would it be possible to add a feature to the debugger that allows one to
debug the 'active' process instead of creating a new process that is then debugged?

In many cases, at least in my experience, what the user wants to do is to
run a command in its current environment under the control of a debugger.
The newly started BlackBox process would act as the debugger and the currently
active BlackBox process is the one that is being debugged.
The operation of the debugger would not be changed, only the roles of the involved processes
are reversed.

WinAPI.DebugActiveProcess seems to be exactly for that purpose.


<<EDITED>>
One more comment:
The old way of passing kernelAdr is to use register EBX.
For BlackBox 1.7.1 the line
kernelAdr := context.(*Ebx*)Edi; (* for old realisation *)
needs to be changed to
kernelAdr := context.Ebx(*Edi*); (* for old realisation *)

- Josef

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Thu Feb 15, 2018 1:35 pm
by Josef Templ
The test for the new versus old style of passing kernelAdr has a little bug, I think.
In "IF string[17] = "[" THEN" the character in string[17] is undefined for the old style
because it is after the terminating 0X character.

While it works in practice, I would suggest to check string[16] # 0X before setting it to 0X
or to save it in an extra character, like:
Code: Select all
ch := string[16]; string[16] := 0X; ...
IF string$ = "BlackBox started" THEN ...
  IF (ch = " ") & (string[17] = "[") THEN ...

In addition, what is passed here in the string is not modList but the address of variable modList
named kernelAdr in the debugger. Therefore it is misleading to output the string
"BlackBox started [modList=xxx]" as the debug string.
I would suggest to use something like "BlackBox started [dbgBase=xxx]".

- Josef

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Sun Feb 18, 2018 6:54 am
by Ivan Denisov
Reasonable suggestions. I think that Center can include this fixes in Kernel. And after your discussions will complete I will conform Obertone version with Center one.

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Sun Feb 18, 2018 7:25 pm
by Josef Templ
There is a problem with missing UTF-8 conversions for variable names, etc.
I think it suffices to change procedure RefName such that it does the conversion.
I have tested this and as far as I have seen it solves all conversion problems.
Please check this.

Code: Select all
   PROCEDURE RefName (VAR ref: INTEGER; VAR n: Name);
      VAR i: INTEGER; ch: SHORTCHAR; uname: Kernel.Utf8Name;
   BEGIN
      i := 0; RefCh(ref, ch);
      WHILE ch # 0X DO uname[i] := ch; INC(i); RefCh(ref, ch) END;
      uname[i] := 0X;
      Strings.Utf8ToString(uname, n, i)
   END RefName;


- Josef

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Tue Feb 20, 2018 6:36 am
by Zinn
Josef Templ wrote:There is a problem with missing UTF-8 conversions for variable names

Josef,
do you remember the micro changes after the last release?
I have done the same kind of Kernel change in GetRefProc & GetRefVar as you success in RefName, but I forgot RefName
There are other Kernel changes pending from OberonCore.
- Helmut

Ivan,
sorry, I forgot to send you a message about this topic. I add my document for you to download.
- Helmut

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Tue Feb 20, 2018 8:22 am
by Josef Templ
Zinn wrote:
Josef Templ wrote:There is a problem with missing UTF-8 conversions for variable names

Josef,
do you remember the micro changes after the last release?
I have done the same kind of Kernel change in GetRefProc & GetRefVar as you success in RefName, but I forgot RefName
There are other Kernel changes pending from OberonCore.
- Helmut

Ivan,
sorry, I forgot to send you a message about this topic. I add my document for you to download.
- Helmut


do you mean changes in RemDebug or elsewhere?

In RemDebug there is the Ebx versus Edi issue and the RefName issue.
There is no need to change anything in GetRefProc & GetRefVar, I think,
because this is covered by the change in RefName.

- Josef

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Wed Feb 21, 2018 7:17 am
by Zinn
Josef,
The Kernel procedures RefName, GetRefProc and GetRefVar deliver names for using it in the BlackBox framework. We have two kinds of representation for names: Unicode (external) and Utf8 (internal). Now you have the problem that RefName deliver the name in the wrong format for the Debug program. I have the same kind of problem in another project that the procedures GetRefProc and GetRefVar deliver the name in the wrong format too. The change of GetRefProc and GetRefVar are running successful in the CPC edition. Why not using the same external format for all 3 procedures?
- Helmut

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Wed Feb 21, 2018 12:56 pm
by Josef Templ
Zinn wrote:Josef,
The Kernel procedures RefName, GetRefProc and GetRefVar deliver names for using it in the BlackBox framework. We have two kinds of representation for names: Unicode (external) and Utf8 (internal). Now you have the problem that RefName deliver the name in the wrong format for the Debug program. I have the same kind of problem in another project that the procedures GetRefProc and GetRefVar deliver the name in the wrong format too. The change of GetRefProc and GetRefVar are running successful in the CPC edition. Why not using the same external format for all 3 procedures?
- Helmut


RemDebug.GetRefProc and RemDebug.GetRefVar are using RemDebug.RefName internally.
By fixing RemDebug.RefName you also fix RemDebug.GetRefProc and RemDebug.GetRefVar.
The external (file) format is UTF-8, the internal format is Unicode.
This has nothing to do with Kernel.GetRefProc etc. Kernel.GetRefProc etc. could also be changed to
return Unicode, but that is an independent topic, I think.

- Josef

Re: Run-time debugger in Blackbox Component Builder

PostPosted: Wed Feb 21, 2018 2:34 pm
by Josef Templ
There is one more little problem in RemDebug when single stepping through <system> code, i.e.
code outside of BlackBox. There is no source code available for such code and
IsBadSourcePos() detects that. However, it returns FALSE in such a case.
To fix that it should return TRUE as shown below. With that fix it skips over
<system> code even when single stepping (F7, F8) is used.
The speed is not very high, though. This results from a lot of interaction
between the program and the debugger just to find out that there is no source code available.
But the alternative, viz. to step through it manually, is much slower.

Code: Select all
      ELSE
         RETURN TRUE
      END
   END IsBadSourcePos;


- Josef