FB debugger : 3.02 32/64 BIT WDS/LNX..... (2023/07/05)

[Dinosaur]

Hi all

SARG, I have not been able to reproduce that, as I need to compile with -gen gcc option on Windows 7.
Has anyone else solved the gcc problem with W7 ?
Will post in Windows re this.

REgards

[SARG]

@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 ?

[AGS]

@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 ?

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.
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.

[SARG]

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]

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"

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.

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_()

In gdb I can see what the type of x is (renamed to tmp$0$):

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];

As you can see tmp$0$ aka X is now declared as a 'regular' struct with
__FB_ARRAYDIMTB$ declared as

Code: Select all

ptype __FB_ARRAYDIMTB$
type = struct ___FB_ARRAYDIMTB$ {
    int ELEMENTS;
    int LBOUND;
    int UBOUND;
}

Very little if any of the above info was available with the asm back end.

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.

[VANYA]

Hi SARG!

In the first post says that you can view the cell arrays, but I do not see how :(
If there is an option please show the screenshot or video, thanks.

[SARG]

Hi VANYA,

Just right click on the variable, click on "select index" then a dialog
box allows you to select the value for each dim. Simple no !!!
You also see the lower and the upper bounds.

[VANYA]

Can not find the conclusion very values ​​in the array. I click on Aplly, but nothing happens :(

[SARG]

See in the variables window : now the index should be changed.

[VANYA]

See in the variables window : now the index should be changed.

All understand now, thanks.

[VANYA]

When you compile a lot of warnings. I corrected now:




Only SourseFile:

http://mneniya.ucoz.ru/FREEBASIC/Public ... bugger.zip

[SARG]

Hi VANYA,

Good job, thanks.
As I'm currently modifying FBDebugger for the -gen option (not so easy), I'll take in account these changes later.

I have seen you're not using the lastest 2.53 version but 2.52.

[AGS]

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?

[SARG]

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.

And no doubt you are busy doing other things.

:-) yes, trying to manage the changes added by the gcc option.

But apart from that: do you consider the above feature(s) useful (an addition to fbdebugger) regardless of who implements these?

Seems interesting and there is at least one interested person ;-).

And are you willing to incorporate code not written by yourself into fbdebugger?

No problem if I understand it ;-).

[AGS]

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):

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