FB debugger : 3.02 32/64 BIT WDS/LNX..... (2023/07/05)
Yes. And I think the gcc back end will (at some moment) become the main back end. I don't see the devs keeping more than one back end up to date.SARG wrote:@Dinosaur
Sorry, it seems that I have been not clear so perhaps there is a mistake. You must not put the -gen gcc option when using fbdebugger as it's not yet compatible.
@All
By the way, are there people interested to 'FBdebug' with that option ?
It would be great to have more people using the gcc back end. And what better way to get them to do just that than debugging support?
I've used insight (you know, the gdb front end) in combination with code produced by gcc. The highlighted line (the 'currently getting executed line') just keeps jumping around. This does not happen as much when using the asm back end.
On the up side: it's easier to get access to variables using the c back end.
If you can get support for the gcc back end going then that would be great. And I would be more very willing to test (and use) it.
New version : slight modification...... see first post.
@AGS
Some weeks ago I began to look at the changes between the 2 options (ASM and GCC) about the debugging. It seems quite possible to do evolve FBdebugger.
But apart a bit of work, some informations disapear during the compilation : multidimensionnal arrays become one dimension,and as you have noticed, the line numbers do not well correspond, so the result is not sure.
I'll try to publish quickly a test version and I be happy if you could use it.
I don't realy understand :"it's easier to get access to variables using the c back end"
@AGS
Some weeks ago I began to look at the changes between the 2 options (ASM and GCC) about the debugging. It seems quite possible to do evolve FBdebugger.
But apart a bit of work, some informations disapear during the compilation : multidimensionnal arrays become one dimension,and as you have noticed, the line numbers do not well correspond, so the result is not sure.
I'll try to publish quickly a test version and I be happy if you could use it.
I don't realy understand :"it's easier to get access to variables using the c back end"
Using insight there seems to be more runtime information available on shared variables (globals) and dynamic arrays (either global or not). The only problem is that insight has a bit of trouble figuring things out.SARG wrote:New version : slight modification...... see first post.
@AGS
Some weeks ago I began to look at the changes between the 2 options (ASM and GCC) about the debugging. It seems quite possible to do evolve FBdebugger.
But apart a bit of work, some informations disapear during the compilation : multidimensionnal arrays become one dimension,and as you have noticed, the line numbers do not well correspond, so the result is not sure.
I'll try to publish quickly a test version and I be happy if you could use it.
I don't realy understand :"it's easier to get access to variables using the c back end"
The dynamic arrays get weird names that are not related to the original name of the variable. Something like tmp$0$.
Example
Code: Select all
redim shared x(0 to 0,0 to 0) as integer
2
3 function do_() as integer
- 4
- 5 for i as integer = 0 to 100
- 6 redim x(0 to i,0 to i)
- 7 next i
8
9 return 0
10
11 end function
- 12
- 13 do_()
Code: Select all
ptype tmp$0$
type = struct _TMP$1 {
int *DATA;
int *PTR;
int SIZE;
int ELEMENT_LEN;
int DIMENSIONS;
__FB_ARRAYDIMTB$ DIMTB[2];
__FB_ARRAYDIMTB$ declared as
Code: Select all
ptype __FB_ARRAYDIMTB$
type = struct ___FB_ARRAYDIMTB$ {
int ELEMENTS;
int LBOUND;
int UBOUND;
}
The debugger could show the content of the dynamic array as the size of the stride and the lower/upper bound of all dimensions of the dynamic array are known.
Of course the debugger has to figure some things out like: what is tmp$0$?
That info is not emitted by the compiler (it gets lost in translation). There is no mapping of variables (there is no info that ties tmp$0$ to X).
I'm pretty sure the devs can make the C back end produce a symbol table. If you look at the code in ir-hlc.bas you can see the name mangling happening (just before the mangling the original name must be known).
Symbolic info that ties C variables to FB variables is what is needed. Without that kind of symbolic info debugging code produced by the C back end might turn out to be a very unpleasant experience.
When you compile a lot of warnings. I corrected now:
Only SourseFile:
http://mneniya.ucoz.ru/FREEBASIC/Public ... bugger.zip
Only SourseFile:
http://mneniya.ucoz.ru/FREEBASIC/Public ... bugger.zip
I've got a feature request that I don't think will be easy to create. The feature.
I'd like the debugger to display the content of what a pointer variable points to as an array or otherwise.
Let me explain by a gdb feature that does just that. It's called an artificial array in GDB. It looks like array@number of elements. example: my_array@100.
It is a usefull feature if you have a pointer that actually stands for a dynamic array and you want to see it's contents. Of course the same could be done with a 'regular' array (wherever I use the word dynamic array the word array could be used as well).
In GDB you can cast that my_array to whatever you want. I'm using that feature to cast a wchar_t ptr to a simple char* as wchar_t is defined as a short and gdb does not understand that wchar_t is actually a unicode character (not a short). So I let insight something like this (some_var is of type wchar_t ptr):
*(char*)some_var@100
I get the above displayed in insight as a tree with 100 members. Half those members contain a 0 but I can also see characters.
As the fbdebugger is written using win32 api it should be possible to add a tree that represents the elements of an array. Right now watch variables are at the bottom in a format that does not lend itself well to represent trees but at the right of the main screen I can see trees (using trees has already been implemented).
Other useful features would be displaying a certain element of a dynamic array (array) and displaying a slice of a dynamic array (array[0-10]). It would be even nicer if that could be done for something other than simple types (udt's). But that would be very hard to get right (I know of only two maybe three IDE's that can display dynamic arrays,lists, trees etc.... in a nice way).
I am well aware that the above feature(s) cannot be implemented easily. And no doubt you are busy doing other things. But apart from that: do you consider the above feature(s) useful (an addition to fbdebugger) regardless of who implements these? And are you willing to incorporate code not written by yourself into fbdebugger?
I'd like the debugger to display the content of what a pointer variable points to as an array or otherwise.
Let me explain by a gdb feature that does just that. It's called an artificial array in GDB. It looks like array@number of elements. example: my_array@100.
It is a usefull feature if you have a pointer that actually stands for a dynamic array and you want to see it's contents. Of course the same could be done with a 'regular' array (wherever I use the word dynamic array the word array could be used as well).
In GDB you can cast that my_array to whatever you want. I'm using that feature to cast a wchar_t ptr to a simple char* as wchar_t is defined as a short and gdb does not understand that wchar_t is actually a unicode character (not a short). So I let insight something like this (some_var is of type wchar_t ptr):
*(char*)some_var@100
I get the above displayed in insight as a tree with 100 members. Half those members contain a 0 but I can also see characters.
As the fbdebugger is written using win32 api it should be possible to add a tree that represents the elements of an array. Right now watch variables are at the bottom in a format that does not lend itself well to represent trees but at the right of the main screen I can see trees (using trees has already been implemented).
Other useful features would be displaying a certain element of a dynamic array (array) and displaying a slice of a dynamic array (array[0-10]). It would be even nicer if that could be done for something other than simple types (udt's). But that would be very hard to get right (I know of only two maybe three IDE's that can display dynamic arrays,lists, trees etc.... in a nice way).
I am well aware that the above feature(s) cannot be implemented easily. And no doubt you are busy doing other things. But apart from that: do you consider the above feature(s) useful (an addition to fbdebugger) regardless of who implements these? And are you willing to incorporate code not written by yourself into fbdebugger?
Hi AGS,
Sorry for my late answer, off during the four latest days.
Currently I see three possibilities :
- in the memory window ('M' button), right click to put the address then select the type (byte, integer,..) to get the correct columns display.
- if you have a pointer variable : select it then right click and 'edit var value'. In this dialog window you have the 'ptr dump' button to directly dump the pointed memory, with the same display options than above.
- An other option with pointer variables, usefull for udts, the 'show/expand variable'. In this case you see a tree with all the values of the udt but only one occurence.
I guess that I can easily add the option to move forward/backward with the size of the udt.
A problem : there is no information about the index of the array.
I'm not sure to correctly answer to your requests. For helping, please post some screencopies.
Sorry for my late answer, off during the four latest days.
Currently I see three possibilities :
- in the memory window ('M' button), right click to put the address then select the type (byte, integer,..) to get the correct columns display.
- if you have a pointer variable : select it then right click and 'edit var value'. In this dialog window you have the 'ptr dump' button to directly dump the pointed memory, with the same display options than above.
- An other option with pointer variables, usefull for udts, the 'show/expand variable'. In this case you see a tree with all the values of the udt but only one occurence.
I guess that I can easily add the option to move forward/backward with the size of the udt.
A problem : there is no information about the index of the array.
I'm not sure to correctly answer to your requests. For helping, please post some screencopies.
:-) yes, trying to manage the changes added by the gcc option.And no doubt you are busy doing other things.
Seems interesting and there is at least one interested person ;-).But apart from that: do you consider the above feature(s) useful (an addition to fbdebugger) regardless of who implements these?
No problem if I understand it ;-).And are you willing to incorporate code not written by yourself into fbdebugger?
I found a couple of smallish bugs (gui bugs).
--> when choosing "show/expand variable" from the pop up menu
(shows up when right clicking on a variable) a dialog appears.
On that dialog there are several buttons. The button below
"Shw String" (typo?) does not show it's label correctly. The button
is not high enough.
--> when clicking "Shw string" in the dialog above (on a non - string variable)
a popup appears with the message "Select only a string variable".
When clicking ok the label "Shw string" changes into something unreadable.
Clicking on anything outside the dialog will change the text of the label
into the correct text again. Clicking on the dialog itself again will make the label change into something unreadable again. Unless you click inside the area where the tree is at (showing the content of the variable). In the latter case the text shows up correct again.
--> when right clicking in the dump screen (the one you get when pressing the M button) you get a dialog. The text beside the radio buttons (dec and hex) show up incomplete. The items of the combo box at the top right (showing a list of types to choose from) are shown incomplete (the combobox is not wide enough).
The word Watch (--> Watc) shows up incomplete.
The last button in the dialog (break on value?) shows up incomplete. The button is not high enough.
I've tried to add support for showing unicode variables when the user presss "show string". I added some code to string_sh and I got it to work. As a wstring is nothing more but a pointer to an ushort it is not hard to show a dynamic array (a pointer to something else) in the same way.
Wstring ends with a '\0' so user does not have to enter start and end of string (slice). This is not true for other dynamic arrays.
Code (not production ready as my additions are not well integrated with rest of the code):
--> when choosing "show/expand variable" from the pop up menu
(shows up when right clicking on a variable) a dialog appears.
On that dialog there are several buttons. The button below
"Shw String" (typo?) does not show it's label correctly. The button
is not high enough.
--> when clicking "Shw string" in the dialog above (on a non - string variable)
a popup appears with the message "Select only a string variable".
When clicking ok the label "Shw string" changes into something unreadable.
Clicking on anything outside the dialog will change the text of the label
into the correct text again. Clicking on the dialog itself again will make the label change into something unreadable again. Unless you click inside the area where the tree is at (showing the content of the variable). In the latter case the text shows up correct again.
--> when right clicking in the dump screen (the one you get when pressing the M button) you get a dialog. The text beside the radio buttons (dec and hex) show up incomplete. The items of the combo box at the top right (showing a list of types to choose from) are shown incomplete (the combobox is not wide enough).
The word Watch (--> Watc) shows up incomplete.
The last button in the dialog (break on value?) shows up incomplete. The button is not high enough.
I've tried to add support for showing unicode variables when the user presss "show string". I added some code to string_sh and I got it to work. As a wstring is nothing more but a pointer to an ushort it is not hard to show a dynamic array (a pointer to something else) in the same way.
Wstring ends with a '\0' so user does not have to enter start and end of string (slice). This is not true for other dynamic arrays.
Code (not production ready as my additions are not well integrated with rest of the code):
Code: Select all
''declaration of MessageBoxW is needed because unicode related functions
''do not get declared when using #include "windows.bi"
extern "windows"
declare function MessageBoxW alias "MessageBoxW" _
( byval hwnd_ as HWND, byval lpText as ushort ptr,_
byval lpCaption as ushort ptr, _
byval uType as UINT _
) as integer
end extern
Sub string_sh(tv as integer)
if var_find2(tv)=0 then exit sub 'search index variable under cursor
''ty 6 = ushort
If varfind.ty<>4 and varfind.ty<>13 and varfind.ty<>14 and varfind.ty <>6 Then 'or ty<>15
fb_message("Show string error","Select only a string variable")
Exit sub
End If
stringadr=varfind.ad
if varfind.pt andalso varfind.ty<>6 Then
ReadProcessMemory(dbghand,stringadr,@stringadr,4,0) 'string ptr
If varfind.pt=2 Then
ReadProcessMemory(dbghand,stringadr,@stringadr,4,0) 'if two levels
End If
End If
If varfind.ty=13 Then 'string
ReadProcessMemory(dbghand,stringadr,@stringadr,4,0)'string address
End If
''AGS
dim my_wstring as integer = stringadr
If (varfind.ty=6) Then 'wstring
ReadProcessMemory(dbghand,my_wstring,@my_wstring,4,0)
dim my_ushort as ushort = 88
dim tmp as wstring ptr = callocate(20,sizeof(wstring))
dim wsize as uinteger = 20
dim k as integer
while (1)
ReadProcessMemory(dbghand,my_wstring,@my_ushort,2,0)
''at end of string
if (my_ushort = 0) then
exit while
end if
if (k = wsize) then
var tmp2 = reallocate(tmp,(wsize + 10) * (sizeof(wstring)))
if (tmp2 = 0) then
MessageBox(0,@"out of memory!",@"problem"),MB_ICONERROR)
deallocate(tmp)
end if
deallocate(tmp)
tmp = tmp2
wsize += 10
end if
tmp[k] = my_ushort
k += 1
my_wstring += 2
wend
''make sure there is a 0 at the end of the wstring
tmp[k] = 0
MessageBoxW(0,tmp,@wstr("wstring content"),MB_OK)
deallocate(tmp)
Else
helptyp=4:fb_dialog(@help_box,"String : "+varfind.nm+" (To change value use dump)" ,windmain,2,2,400,250)
End If
End Sub