Run-time debugger in Blackbox Component Builder

Usage of the framework, compiler and tools
User avatar
Ivan Denisov
Posts: 362
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

Post 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
Zinn
Posts: 123
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main
Contact:

Re: Run-time debugger in Blackbox Component Builder

Post 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
Attachments
D02.txt
(18.46 KiB) Downloaded 510 times
Josef Templ
Posts: 262
Joined: Tue Sep 17, 2013 6:50 am

Re: Run-time debugger in Blackbox Component Builder

Post 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
Zinn
Posts: 123
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main
Contact:

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

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

Re: Run-time debugger in Blackbox Component Builder

Post 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
Post Reply