Run-time debugger in Blackbox Component Builder

Usage of the framework, compiler and tools

Re: Run-time debugger in Blackbox Component Builder

Postby Ivan Denisov » Tue Feb 06, 2018 7:28 am

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.
User avatar
Ivan Denisov
 
Posts: 226
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Thu Feb 15, 2018 9:06 am

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Thu Feb 15, 2018 1:35 pm

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Postby Ivan Denisov » Sun Feb 18, 2018 6:54 am

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.
User avatar
Ivan Denisov
 
Posts: 226
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Sun Feb 18, 2018 7:25 pm

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Postby Zinn » Tue Feb 20, 2018 6:36 am

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
Attachments
D02.txt
(18.46 KiB) Downloaded 67 times
Zinn
 
Posts: 58
Joined: Mon Nov 24, 2014 10:47 am

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Tue Feb 20, 2018 8:22 am

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Postby Zinn » Wed Feb 21, 2018 7:17 am

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
Zinn
 
Posts: 58
Joined: Mon Nov 24, 2014 10:47 am

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Wed Feb 21, 2018 12:56 pm

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Postby Josef Templ » Wed Feb 21, 2018 2:34 pm

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
Josef Templ
 
Posts: 195
Joined: Tue Sep 17, 2013 6:50 am

Previous

Return to Common questions

Who is online

Users browsing this forum: No registered users and 1 guest

cron