Problem with GoBug

[Roger]

Hi All,

I have the following snippets in a program which I am translating from 16 to 32 bit code and now debugiing:-

Code Select Expand


data
tib_at: DD  0000h
Code


start:
Jmp start2

. . . . .

Start2:
cli
mov ebp,addr irstack
mov eax,addr reset                  ;load first address
jmp eax


Docol:
xchg ebp,esp                  ;X
push esi                      ;X             ; push address pointer
xchg ebp,esi                   ;X
add eax,05                     ;Y
mov esi,eax ; current address to pointer
lodsd
jmp eax


exit:
xchg ebp,esp              ;X
pop esi                      ;X              ; pop address pointer
xchg ebp,esi               ;X
add eax,05                 ;Y              ; pass jmp docol inst
mov esi,eax
lodsd
jmp eax


Lit:
push ebx
lodsd
mov ebx,eax                             ;l fetch immediate
lodsd
jmp eax


tib:
push ebx
mov ebx,addr tib_at
lodsd
jmp eax


store:
pop eax
mov [ebx],eax
pop ebx
lodsd
jmp eax


reset:
jmp docol
DD  lit, Text_Buff
DD  tib, store

. . . . .



This part of the code seems to be working as the program runs past this point.
However when I try to single step [F5] through it everything stops at the at the 6 instructions marked :X , the keyboard and mouse die and I have to reboot. I am sure this must be a quirk of the dubuging process because lf I set  break points at ;Y and use [F9] to run through the instuctions ;X it keeps on working .

I would like to know if this is a problem with GoBug or with with Windows API.

The code is assembled using GoAsm and GoLink and is beingrun under Win95

Regards Roger

[BogdanOntanu]

This looks like a part from a FORTH subsystem

If you want to port it on windows I will suggest that you : UPGRADE CLI DROP;  :D

If it is not your own code then again I suggest that you drop it since rules of this forum DO NOT ALLOW IT!

FORTH has an internal very small virtual maching (6 instructions looks ok)
and yes it is most likely that unless you hit a PRIMITIVE WORD you will keep on cycling in this area.

Decompiling FORTH is very easy but other techniques are required.
And if you do not understand FORTH concepts -->  then it is going to be relatively hard to port... otherwise it is very easy.

Again IF you are porting to Windows --> then you will first have to port the primitive keywords used to interact with the keyboard and output on screen.
For a start a simple console application will do. I also suggest that you use EBX or another register for FORTH return stack address since EBP register has stack frame related usage in procedures and it will somehow hinder the later usage of API's or STDCALL procedures in your  port...

I honestly do not think that this is a problem of GoBug... but you could also try OllyDbg just to check

Ah, and the LIT primitive does not look right to me...
On execution time LIT should have read the next dword from the current execution path and push it on parameter stack as a number
Your LIT code there looks more like THICK CFA EXECUTE
However do not see the "docol" aka ":" definition in sight ... so I can not be sure...

[Roger]

Hi Bogdan,

I am still trying it with OllyDbg with uncertain results. It still jams but not in the same place and dosen't seem to hang up the OS as well. It doesn't help having GoBug on one machine (Win95) and OllyDbg  on another (XP) making direct comparisons less equal.

However I think you may have missunderstod my problem.  It is not that the program won't run because it will - at least the front end. It is that I can't single step through it. It will run though the problem parts to a break point but I can't use the single step animate it without locking up, not just GoBug, but everything.

The original 16 bit code was written for a 80188 based embedded processor I designed for a telephone system manufacturer I was working for and I am still using it and the prototype cpu boards. The original code was developed on DOS so it could be debuged using DOS tools (A86, D86) since I only had simple tools on the embedded card.  It is this version that I am porting to 32 bit so I know that the structure of the FORTH is good. Furthermore I can single step the 32 bit version as far as putting the title text string onto the console.  It's just that each time I fix a bug or step when I should have run, I have to start over stepping in from the begining - and it gets further each time - and I have to reboot from BSOD each time. :boohoo:

BTW LIT is fine. The top item on the stack is kept in BX/EBX which is one reason I dont want to change the usge of EBX if I don't have to.

Regards Roger