Oxygen Basic

Programming => Tools => Topic started by: Laurent on May 23, 2018, 03:30:11 PM

Title: 02debugger : a debugger for o2
Post by: Laurent on May 23, 2018, 03:30:11 PM
Hi all
I'm the fbdebugger's dev. Currently I'm adapting the debugger to O2. Thanks to Charles for the information he sent me.

http://users.freebasic-portal.de/sarg/02debugger.zip

Quick start
- For direct use : oxygen.dll and o2debugger.exe (for now 32bit but 64bit should work when compiling under 64bit).

- Or compile the dll as usually with the provided files (modified version B0 2018/03/29)
     compile o2debugger : fbc - console 02debugger.bas with button directory and rc.file in same directory.

- Compile 02bas files with the new dll, just adding a line at the top of main file, as in the example ''debug<path/name>.o2bas##
  You get an <name>_dbg.exe just to distinguish it from the nodebug one.

- Execute o2debugger and select the exe with the "directory" button or drag and drop on the left window

Refer to the help file and complementary text file for more information. It is about fbdebugger but most of the features are identical.

Feel free to ask (o2 forum or debug@aliceadsl.fr) for help and above all report every issue you could encounter, with a (small) example.


NB
- No change is done in the executable part only add of debugging data hence the exe size is obviously greater
- It's a beta version so some features are missing (WIP message) and there is a bit of work to get a polished version.
  Besides I do not know all the syntaxes of O2 well....
- The RTL32/64 includes are skipped. Is it a good thing to do the same with the other includes ?

- I keep Freebasic language because easier for me and reuse max of code.
- I hope Charles will better integrate my modifications in the original code :-)
Title: Re: 02debugger : a debugger for o2
Post by: JRS on May 23, 2018, 04:02:43 PM
Welcome Laurent!

It's great to see O2 attract this class of talent.

Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on May 24, 2018, 05:55:20 AM
Welcome to our forum, Laurent.

I have never used a debugger before, and have always relied on technique rather than technology to track and eliminate bugs. The most difficult ones, like indirect recursions in the o2 source code, can take around 4 to 8 hours to resolve. I don't know how a debugger would offer a significant advantage over a console and some well-chosen print statements. But I'm willing to learn. Perhaps some of the essentials can be built into o2 itself, such as a run-time procedure tracer.
Title: Re: 02debugger : a debugger for o2
Post by: JRS on May 24, 2018, 06:52:06 AM
Code: Script BASIC
  1. PRINT "Got Here!\n"
  2.  

What I use for 90% of my debugging.  :)
Title: Re: 02debugger : a debugger for o2
Post by: Mike Lobanovsky on May 24, 2018, 07:02:53 AM
Hi Laurent,

Welcome to the O2 forum and thank you very much for your contribution!

Can you please elaborate on the license status of your debugger's source code and resources (bitmaps)? OxygenBasic is in the Public Domain, and we would like to know the exact extent to which we're allowed to modify and/or possibly reuse the debugger code, in whole or in part, when and if we see fit.

Not all open source licenses are compatible with the Public Domain, and the compilers based on the O2 engine may or may not even be free or open source at all, at the end-product developer's own option.

TIA
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on May 27, 2018, 02:17:47 AM
Hi all and thank you for the welcome, :)

@John, Charles
A debugger allows you to run step by step or run to a line, see (and modify) the variable/parameter values at anytime without putting print everywhere.
With o2debugger you can also log the execution for later analyze,  see several elements of an array, see large area of memory displayed by a selected type (integer, short, etc), see all the field of structure, see the chaining of procedures (called by and so), execute automatically a step by step with a small pause and even change the execution (in a same procedure) to skip line(s) or to reexecute one(s). And many other features.
Just give it a try. I need some reports to fix (surely) existing issues.

I use also print but it's often faster finding the reason of bug with a debugger. As always don't use a drop hammer just for a nail :-)

@Mike
Consider that you can use everything you want. I wrote all the code and except two icons based on standard I drew the other ones.
Anyway ask me if you are going to do something with them.

@Charles
Strangely I have received two messages about splitting and merging this topic ???
Title: Re: 02debugger : a debugger for o2
Post by: Arnold on May 27, 2018, 03:28:56 AM
Hi Laurent,

I have not yet tried O2debugger.exe, but I think it could be very helpful in cases when O2 compiles successfully but crashes at runtime.

Can o2debugger.exe be used with oxygen.dll of the latest Oxygenbasic distribution or must it be used with oxygen.dll which you provided with your contribution? (could be a small disadvantage)

Roland
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on May 27, 2018, 07:47:50 AM
Hi Arnold,

No it's not possible as the data necessary for debugging is only added in "my" version. However there are not a lot of modifications and I'll provide a new version quickly, no later than tomorrow.


By the way the right command  for compiling o2debugger is : fbc -s gui o2debugger. A console is opened by the exe if needed.
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on May 27, 2018, 02:45:50 PM
Modifications done for version B0 2018-05-24 T 12:49:29

02 code source and dll provided. : http://users.freebasic-portal.de/sarg/02src20180528.zip

@John please do not mix subjects. :)

Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on May 27, 2018, 07:24:56 PM
Hi Laurent,

Which parts of o2 did you have to modify?
Title: Re: 02debugger : a debugger for o2
Post by: Mike Lobanovsky on May 27, 2018, 09:41:02 PM
(Charles,

Alongside a more common WinDiff, WinMerge (http://winmerge.org/?lang=eng) is another excellent tool to easily locate, examine and process the differences between various versions of same documents, predominantly program sources. I'm using it on a day-to-day basis.)
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on May 28, 2018, 05:33:41 AM
Quote from: Charles Pegge
Hi Laurent,

Which parts of o2 did you have to modify?
Hi Charles,

Only 8 files have been modified :
Oxygen
o2decl
o2glob
o2hdrs (max modified file)
o2link
o2meta
o2sema
o2tran

Every modifcation is marked with ''mod DBG. If several lines added the end is also marked by ''end of mod or ''end of DBG.
Mostly  lines are added and sometimes replaced or just a instruction added.

For now ''debug <name of main code file>## is mandatory at top of user's main file to trigger the add of debugging data and get the file name.
eg ''debug D:\OxygenBasicProgress\OxygenBasic\test.o2bas##

Then a flag dbgf is set on. Without it no change is made in the exe.

It would be cool to have an option -d like -c to do that. there are just changes in co2.exe to transmit the file name.

Currently only the rtlxx.inc are skipped maybe all the other ones could be also skipped to avoid unusefull information. Your advice ?
I'll remove all the temporary variables (named TEMPOxx in o2debugger) added by the compiler. Your advice ?

@Mike
In this case I'm using a batch with the tool diff.exe to find all the changes made in a set of files. It generates for each pair of files a text file with their differences, in a way a bit raw ;)
for %%F in (*.bas) do <path_diff>diff.exe %%F <path2>%%~nxF >diff%%~nF.txt
The batch file is executed in the first directory to compare files in the second directory (path2). An example of name: diffo2tran.txt.

@Admins
Thank you for the spiltting.
Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on May 28, 2018, 08:11:12 AM
I could provide per-line and per-procedure callbacks. Then you would not need to touch the source code, and it would work for all future versions of o2.

Title: Re: 02debugger : a debugger for o2
Post by: JRS on May 28, 2018, 08:46:49 AM
That sounds a little like the SB preprocessor approach and I like it.
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on May 28, 2018, 12:42:34 PM
Quote from: Charles Pegge
I could provide per-line and per-procedure callbacks. Then you would not need to touch the source code, and it would work for all future versions of o2.

Sorry not sure to understand how it would work anyway a lot of information is missing.
Below in detail the data necessary for debugging (to fill the corresponding section). In order to reduce the mods (mainly in o2hdrs) all of that could be put in an external file instead to be embedded in the exe. However I can assume the integration at least as long as it's FB code.

- Line addresses (filled when linking) with file index, proc index and line number.
- First and last executable lines of procedures
- file code names in same order than lines   
- structures
- procedures in same order than lines with file index and first line followed by their parameters and variables with type/address/indirect/dim/indexbase
 
Code: [Select]
.dbgdata
hl00000000 hw0000 hw0000 hw0001
hl00000000 hw0000 hw0000 hw0002
hl00000000 hw0000 hw0000 hw0003
hl00000000 hw0000 hw0000 hw0005
hl00000000 hw0000 hw0000 hw0008
hl00000000 hw0000 hw0000 hw0009
hl00000000 hw0000 hw0000 hw000F
hl00000000 hw0000 hw0001 hw0010
hl00000000 hw0000 hw0001 hw0011
hl00000000 hw0000 hw0001 hw0012
hl00000000 hw0000 hw0001 hw0013
hl00000000 hw0000 hw0001 hw0014
hl00000000 hw0000 hw0001 hw0015
hl00000000 hw0000 hw0001 hw0016
hl00000000 hw0000 hw0000 hw001C
hl00000000 hw0000 hw0002 hw001D
hl00000000 hw0000 hw0002 hw001E
hl00000000 hw0000 hw0002 hw001F
hl00000000 hw0000 hw0002 hw0026
hl00000000 hw0000 hw0000 hw002A
hl00000000 hw0000 hw0000 hw002B
hl00000000 hw0000 hw0000 hw002C
hl00000000 hw0000 hw0000 hw0032
hl00000000 hw0000 hw0000 hw0033
hl00000000 hw0000 hw0000 hw0035
hl00000000 hw0000 hw0000 hw0036
hl00000000 hw0000 hw0000 hw0037
hl00000000 hw0000 hw0000 hw0038
hl00000000 hw0000 hw0000 hw003A
hl00000000 hw0000 hw0000 hw003C
hl00000000 hw0000 hw0000 hw003E
hl00000000 hw0000 hw0000 hw0040
hl00000000 hw0000 hw0000 hw0041
hl00000000 hw0000 hw0000 hw0042
hl00000000 hw0000 hw0000 hw0043
hl00000000 hw0000 hw0000 hw0044
hl00000000 hw0000 hw0000 hw0045
hl00000000 hw0000 hw0000 hw0047
hl00000000 hw0000 hw0000 hw0049
hl00000000 hw0000 hw0000 hw004B
hl00000000 hw0000 hw0000 hw004C
hl00000000 hw0000 hw0000 hw004D
hl00000000 hw0000 hw0000 hw004F
hl00000000 hw0000 hw0000 hw0051
hl00000000 hw0001 hw0000 hw0001
hl00000000 hw0001 hw0003 hw0002
hl00000000 hw0001 hw0003 hw0003
hl00000000 hw0001 hw0003 hw0005
hl00000000 hw0000 hw0000 hw0054
hl00000000 hw0000 hw0000 hw005E
hl00000000 hw0000 hw0000 hw0060
hl00000000 hw0000 hw0000 hw0064
hl00000000 hw0000 hw0000 hw0065
hl00000000 hw0000 hw0000 hw0066
hl00000000 hw0000 hw0000 hw0069
hl00000000 hw0000 hw0004 hw006A
hl00000000 hw0000 hw0004 hw006B
hl00000000 hw0000 hw0004 hw006C
hl00000000 hw0000 hw0004 hw006D
hl00000000 hw0000 hw0004 hw006E
hl00000000 hw0000 hw0004 hw006F
hl00000000 hw0000 hw0004 hw0070
hl00000000 hw0000 hw0004 hw0071
hl00000000 hw0000 hw0004 hw0072
hl00000000 hw0000 hw0004 hw0073
hl00000000 hw0000 hw0004 hw0074
hl00000000 hw0000 hw0004 hw0075
hl00000000 hw0000 hw0004 hw0076
hl00000000 hw0000 hw0000 hw0078
hl00000000 hw0000 hw0000 hw007A
hl00000000 hw0000 hw0000 hw007B
hl00000000 hw0000 hw0000 hw007D
hl00000000 hw0000 hw0000 hw007E
hl00000000 hw0000 hw0000 hw007F
hl00000000 hw0000 hw0000 hw0080
hl00000000 hw0000 hw0000 hw0081
hl00000000 hw0000 hw0000 hw0082
hl00000000 hw0000 hw0000 hw0083
hl00000000 hw0000 hw0000 hw0084
hl00000000 hw0000 hw0000 hw0000
.dbgprad
hl00000000 hl00000000
hl00000000 hl00000000
hl00000000 hl00000000
hl00000000 hl00000000
ga _main_  hl00000000
hl00000000
gd 0 2F 00 "F:D:\OxygenBasicProgress\OxygenBasic\test.o2bas"
gd 0 0F 00 "F:testinc.o2bas"
gd 0 E9 00 "T:rectangle 20
datain 4 0 0       9 AA #sys#sys#sys#sys#sys@00000 sys
show 4 4 0       9 AA @ string
/\
posx 4 0 0 1 AA , sys
posy 4 4 0 1 AA , sys
lenx 4 8 0 1 AA , sys
leny 4 12 0 1 AA , sys
color 4 16 0 1 AA , sys
"
gd 0 6C 00 "T:tsubudt 8
fsubshort 2 0 0 1 AA , short
fsubbyte 1 2 0 1 AA , byte
fsubinteger 4 4 0 1 AA , integer
"
gd 0 40 01 "T:tudt 24
fsys 4 0 0 1 AA , sys
fbyte 1 4 0 1 AA , byte
flong 4 8 0 1 AA , long
fsubudt 8 12 0 5 AA , tsubudt
fsubudt.fsubshort 2 12 0 1 AA , short
fsubudt.fsubbyte 1 14 0 1 AA , byte
fsubudt.fsubinteger 4 16 0 1 AA , integer
 
     
uinteger 4 20 0 1 AA , sys
ubyte 1 20 0 1 AA , byte
            "
gd 0 29 00 "T:simple 4
fsimp 4 0 0 1 AA , integer
"
gd 0 14 00 "P:method datain 0 15"
gd 0 2D 00 "V:this t=rectangle a=[ebp+0x8] i=1 k=0 d= b=1"
gd 0 28 00 "V:param t=sys a=[ebp+0xC] i=0 k=0 d= b=1"
gd 0 24 00 "V:pdata t=sys a=[ebp] i=0 k=0 d= b=1"
gd 0 25 00 "V:px t=sys a=[ebp+0xC] i=0 k=0 d= b=1"
gd 0 26 00 "V:py t=sys a=[ebp+0x10] i=0 k=0 d= b=1"
gd 0 26 00 "V:lx t=sys a=[ebp+0x14] i=0 k=0 d= b=1"
gd 0 26 00 "V:ly t=sys a=[ebp+0x18] i=0 k=0 d= b=1"
gd 0 28 00 "V:rgba t=sys a=[ebp+0x1C] i=0 k=0 d= b=1"
gd 0 12 00 "P:method show 0 28"
gd 0 2D 00 "V:this t=rectangle a=[ebp+0x8] i=1 k=0 d= b=1"
gd 0 28 00 "V:param t=sys a=[ebp+0xC] i=0 k=0 d= b=1"
gd 0 24 00 "V:pdata t=sys a=[ebp] i=0 k=0 d= b=1"
gd 0 2E 00 "V:_retval t=string a=[ebp-0x10] i=0 k=0 d= b=1"
gd 0 2A 00 "V:tab t=string a=[ebp-0x14] i=0 k=0 d= b=1"
gd 0 2D 00 "V:cr t=string a=[ebp-0x1C] i=0 k=0 d=2 2  b=1"
gd 0 27 00 "V:2 t=long a=[ebp-0x20] i=0 k=0 d= b=1"
gd 0 11 00 "P:sub testsub 1 1"
gd 0 28 00 "V:param t=sys a=[ebp+0x8] i=0 k=0 d= b=1"
gd 0 24 00 "V:pdata t=sys a=[ebp] i=0 k=0 d= b=1"
gd 0 2B 00 "V:vshort t=short a=[ebp+0x8] i=1 k=0 d= b=1"
gd 0 27 00 "V:a t=short a=[ebp-0x10] i=0 k=0 d= b=1"
gd 0 27 00 "V:9 t=long a=[ebp-0x14] i=0 k=0 d= b=1"
gd 0 16 00 "P:function test2 0 105"
gd 0 28 00 "V:param t=sys a=[ebp+0x8] i=0 k=0 d= b=1"
gd 0 24 00 "V:pdata t=sys a=[ebp] i=0 k=0 d= b=1"
gd 0 2D 00 "V:totval t=integer a=[ebp+0x8] i=0 k=0 d= b=1"
gd 0 2D 00 "V:totref t=integer a=[ebp+0xC] i=1 k=0 d= b=1"
gd 0 2A 00 "V:titi t=float a=[ebp+0x10] i=0 k=0 d= b=1"
gd 0 2E 00 "V:motheref t=short a=[ebp+0x14] i=1 k=0 d= b=1"
gd 0 2C 00 "V:_retval t=byte a=[ebp-0x10] i=0 k=0 d= b=1"
gd 0 29 00 "V:param t=sys a=[ebp-0x14] i=0 k=0 d= b=1"
gd 0 2E 00 "V:_tatax t=integer a=[ebp-0x18] i=1 k=0 d= b=1"
gd 0 39 00 "V:staticshort t=short a=[ebx+0x1278] i=0 k=0 d=89 89  b=1"
gd 0 29 00 "V:tata t=byte a=[ebp-0x1C] i=0 k=0 d= b=1"
gd 0 25 00 "V:14 t=8 a=[ebp-0x24] i=0 k=0 d= b=1"
gd 0 0F 00 "P:sub main: 0 1"
gd 0 39 00 "V:rectangle_table t=sys a=[ebx+0x1000] i=0 k=0 d=2 2  b=1"
gd 0 2E 00 "V:mtest t=string a=[ebx+0x1008] i=0 k=0 d= b=1"
gd 0 34 00 "V:vsub t=tsubudt a=[ebx+0x100C] i=0 k=0 d=10 10  b=1"
gd 0 39 00 "V:locintarr t=integer a=[ebx+0x105C] i=0 k=0 d=77 77  b=1"
gd 0 3A 00 "V:redimshort_buffer t=string a=[ebx+0x1190] i=0 k=0 d= b=1"
gd 0 36 00 "V:redimshort_count t=int a=[ebx+0x1194] i=0 k=0 d= b=1"
gd 0 32 00 "V:redimshort t=short a=[ebx+0x1198] i=1 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qb t=sys a=[ebx+0x119C] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_le t=sys a=[ebx+0x11A0] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qn t=sys a=[ebx+0x11A4] i=0 k=0 d= b=1"
gd 0 26 00 "V:3 t=8 a=[ebx+0x11A8] i=0 k=0 d= b=1"
gd 0 30 00 "V:rect t=rectangle a=[ebx+0x11B0] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qb t=sys a=[ebx+0x11C4] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_le t=sys a=[ebx+0x11C8] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qn t=sys a=[ebx+0x11CC] i=0 k=0 d= b=1"
gd 0 26 00 "V:4 t=8 a=[ebx+0x11D0] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qb t=sys a=[ebx+0x11D8] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_le t=sys a=[ebx+0x11DC] i=0 k=0 d= b=1"
gd 0 33 00 "V:redimshort_qn t=sys a=[ebx+0x11E0] i=0 k=0 d= b=1"
gd 0 26 00 "V:5 t=8 a=[ebx+0x11E4] i=0 k=0 d= b=1"
gd 0 29 00 "V:7 t=long a=[ebx+0x11EC] i=0 k=0 d= b=1"
gd 0 34 00 "V:vbyte t=byte a=[ebx+0x11F0] i=0 k=0 d=100 100  b=0"
gd 0 2A 00 "V:11 t=long a=[ebx+0x1254] i=0 k=0 d= b=1"
gd 0 2A 00 "V:13 t=long a=[ebx+0x1258] i=0 k=0 d= b=1"
gd 0 31 00 "V:vglobal t=integer a=[ebx+0x125C] i=0 k=0 d= b=1"
gd 0 2B 00 "V:vudt t=tudt a=[ebx+0x1260] i=0 k=0 d= b=1"
gd 0 2F 00 "V:mtata t=integer a=[ebx+0x132C] i=0 k=0 d= b=1"
gd 0 2F 00 "V:mtotr t=integer a=[ebx+0x1330] i=0 k=0 d= b=1"
gd 0 2E 00 "V:mtutu t=double a=[ebx+0x1334] i=0 k=0 d= b=1"
gd 0 30 00 "V:motheref t=short a=[ebx+0x133C] i=0 k=0 d= b=1"
gd 0 2A 00 "V:16 t=long a=[ebx+0x1340] i=0 k=0 d= b=1"
gd 0 2F 00 "V:iloop t=integer a=[ebx+0x1344] i=0 k=0 d= b=1"
gd 0 2A 00 "V:17 t=long a=[ebx+0x1348] i=0 k=0 d= b=1"
gd 0 2A 00 "V:19 t=long a=[ebx+0x134C] i=0 k=0 d= b=1"
gd 0 1A 00 "D:B0 2018-05-24 T 12:49:29"
00 00 00 01 `end_of_dbgdata` 01 /+1000
Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on May 28, 2018, 02:18:37 PM
A simpler alternative is to embed the debugger interface, as o2 source code which could be included in any program being tested. This would make it much easier to access variables and structures

It requires a very small addition to o2, for invoking the debugger per-procedure or per-line.

Title: Re: 02debugger : a debugger for o2
Post by: JRS on May 28, 2018, 02:42:37 PM
I like this idea better than an external debugger. I could use it with DLLC.
Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on May 29, 2018, 06:16:11 AM
(Charles,

Alongside a more common WinDiff, WinMerge (http://winmerge.org/?lang=eng) is another excellent tool to easily locate, examine and process the differences between various versions of same documents, predominantly program sources. I'm using it on a day-to-day basis.)


Mike,

I'm eager to understand the diff algorithms. In a slightly different form, they could be very useful for matching code-patterns in large projects. This would be very useful for abstraction and optimisation.
Title: Re: 02debugger : a debugger for o2
Post by: JRS on May 29, 2018, 06:45:51 AM
If O2 used Github as intended, you would already have the tools your interested in.
Title: Re: 02debugger : a debugger for o2
Post by: Arnold on June 01, 2018, 10:59:19 AM
Hi Charles, Laurent,

hopefully my intention is not misinterpreted.

This is the code of an older example (classLibraryCompo.o2bas). In the original state it will crash. It will crash if I uncomment line 68 and comment line 69-71. It will also crash if I comment line 68-line 71, or comment line 68,70,71 and keep line 69. As is (using the print statements) it will work.

I assume something is missing with Oxygen.dll. But how would I find the problem using O2debugger.exe or the new tracer facility of Oxygen or any other tool? Currently I only use print statements and trial and error, but somehow I think I should act more systematically.

Roland

Code: OxygenBasic
  1.  
  2. '
  3. '
  4. '
  5. '         ###############
  6. '       ###################
  7. '      ###               ###
  8. '     ###    ###          ###
  9. '    ###    ## ##         ###
  10. '    ###   ##   ##        ###
  11. '    ###  ##     ##       ###
  12. '    ###  ##      ##      ###
  13. '    ###  ##      ##      ###
  14. '    ###   ####  ##      ###
  15. '     ###    ####       ###
  16. '      ###             ###
  17. '       ###           ###
  18. '         #############
  19. '           #########
  20.  
  21.  
  22. '-------------
  23. 'CLASS LIBRARY
  24. '=============
  25.  
  26.   'Oxygen dependent
  27.  '#file "greeting.dll"
  28.  
  29.   'Oxygen independent
  30.  includepath "$/inc/"
  31.   '$dll
  32.  '$filename "greeting.dll"
  33.  '#include "RTL32.inc" 'UNCOMMENT
  34.  
  35.   extern
  36.  
  37.   class greeting
  38.   '=============
  39.  
  40.   bstring hi,bye
  41.  
  42.   method hello(string n)
  43. 'print "in method hello"  
  44.  print hi n
  45.   end method
  46.  
  47.   method goodbye(string n)
  48.   print bye n
  49.   end method
  50.  
  51.   method free()
  52.   del hi
  53.   del bye
  54.   del this
  55.   print "freed"
  56.   end method
  57.  
  58.   end class
  59.  
  60.   '#recordof greeting
  61.  
  62.  
  63.   function NewGreetingObject() as greeting*, export
  64.   =================================================
  65.   new greeting g  
  66.   g.hi="Hello "
  67.   g.bye="Goodbye "
  68. 'print "new greeting g = " @g
  69. sys *address = @g  
  70. print "new greeting address = " @address
  71. print "new greeting @g = " @g
  72.   return @g
  73.   end function
  74.  
  75.   end extern
  76.  
  77.  
  78.   extern virtual
  79.   class greeting
  80.   ==============
  81.   method hello(string n)
  82.   method goodbye(string n)
  83.   method free()
  84.   end class
  85.   end extern
  86.  
  87.   'declare NewGreetingObject lib "greeting.dll" () as greeting
  88.  
  89.   greeting g at NewGreetingObject()
  90. 'print "@g = " @g  
  91.  g.hello   "world"
  92.   g.goodbye "world"
  93.   g.free
  94.  
Title: Re: 02debugger : a debugger for o2
Post by: Laurent on June 01, 2018, 12:11:10 PM
Hi Arnold, Roland,

No need o2debugger here : the compiler is indeed involved.

Lorand (same pronunciation in french than Laurent)

A simpler alternative is to embed the debugger interface, as o2 source code which could be included in any program being tested. This would make it much easier to access variables and structures

It requires a very small addition to o2, for invoking the debugger per-procedure or per-line.
I'm sure that will limit the debug possibilities. If the goal is just to follow the execution ok but to see the variable values and other nice features not possible. Trust me. Just have a look to the chm file. I could later explain how a debugger works.
For now I continue to complete the missing features. I'll reduce le number of lines modified in the O2 dll source code and see how generate the debugging data an external file.
Title: Re: 02debugger : a debugger for o2
Post by: Mike Lobanovsky on June 02, 2018, 01:11:12 AM
Lorand (same pronunciation in french than Laurent)

Nah, not quite: "o" in "Lor..." is open like in "alors" while "o" in "Laur..." is deep like in "l'eau", n'est-ce pas? But yes, "...rand" is pretty much the same as "...rent" indeed. :)

Hi there, Mr Roland "Arnold" Lorand! :D

Title: Re: 02debugger : a debugger for o2
Post by: Charles Pegge on June 03, 2018, 02:02:31 AM
Hi Roland,

I think you can systematise the location of bugs. But the rest of the bug-fixing process will often involve running a series of code modifications to establish the behaviour of the code, followed by a detailed step-through to understand the erratic behaviour, and then a consideration of the best solution to the problem. These latter stages, which consume the most time, require a range of skills which I doubt could be automated.

Anyway, the example you gave was an interesting one, and is restored to the OOP examples. It took about 30 mins to characterize the bug symptoms, another hour to identify the behaviour at the assembler level. Another hour to trace the origin of the bug. 1 minute for a quick fix: A mere d=0. Then another hour or two to go for a deeper, and more robust fix, saving some lines of code in the process.

Title: Re: 02debugger : a debugger for o2
Post by: Arnold on June 03, 2018, 08:01:01 AM
Hi Charles,

probably my approach is wrong. It is clear now that I must ask if it is about the compiler. But I work on some small projects which do not yet work quite correctly and I am sure this happens because of my faulty logic. In the meantime it is my ambition not to ask you about trifles every time.

I will try O2debugger with some working examples. This should give a better insight into the possible use of a debugger, which is another new territory for me.

@Mike,
I once selected an anagram as member name and did not notice the consequences. But this is ok. Unfortunately I see my messages like little letters which need a signature. In this regard I behave like the guy in "The Big Bang Theory" who can not get rid of his habits. And I must admit it is not so easy to do this. It is like giving up smoking.
Title: Re: 02debugger : a debugger for o2
Post by: Mike Lobanovsky on June 03, 2018, 09:23:20 AM
Roland,

Your messages are perfect! They are descriptive, informative, and precise to the most minute detail. Please keep up posting in this very style. I enjoy reading them all, even if I don't always respond. :)