Run-time debugger in Blackbox Component Builder
- Ivan Denisov
- Posts: 362
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Run-time debugger in Blackbox Component Builder
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.
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.
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
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
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
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
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:
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
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 ...
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
- Ivan Denisov
- Posts: 362
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Run-time debugger in Blackbox Component Builder
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.
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
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.
- Josef
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;
Re: Run-time debugger in Blackbox Component Builder
Josef,Josef Templ wrote:There is a problem with missing UTF-8 conversions for variable names
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 618 times
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
do you mean changes in RemDebug or elsewhere?Zinn wrote:Josef,Josef Templ wrote:There is a problem with missing UTF-8 conversions for variable names
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
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
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
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
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
RemDebug.GetRefProc and RemDebug.GetRefVar are using RemDebug.RefName internally.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
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
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Run-time debugger in Blackbox Component Builder
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.
- Josef
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;