FB debugger : 3.02 32/64 BIT WDS/LNX..... (2023/07/05)
Re: FB debugger : 2.70 BETA 2 (august 23, 2013)
Thank you once again, SARG, for your new and even better version of fbDebugger.
You may remember I requested a feature some time ago which I called "Call stack" (see here), as it is called in popular debuggers for other programming languages. I wasn't able to explain exactly to you, what it should be and behave like.
The context-menu command "Locate calling line" was a first step towards what I had in mind. The new feature you are calling "Backtracking" comes quite close to what I meant when I wanted a "Call stack". It's just a different representation. You can imagine the call stack as a list of all "current" locations seen in the Backtracking dialog when navigating from the current execution procedure up to the most top procedure (in the Backtracking dialog using the "prev" button).
You may remember I requested a feature some time ago which I called "Call stack" (see here), as it is called in popular debuggers for other programming languages. I wasn't able to explain exactly to you, what it should be and behave like.
The context-menu command "Locate calling line" was a first step towards what I had in mind. The new feature you are calling "Backtracking" comes quite close to what I meant when I wanted a "Call stack". It's just a different representation. You can imagine the call stack as a list of all "current" locations seen in the Backtracking dialog when navigating from the current execution procedure up to the most top procedure (in the Backtracking dialog using the "prev" button).
Re: FB debugger : 2.70 BETA 2 (august 23, 2013)
It's a pleasure.St_W wrote:Thank you once again, SARG, for your new and even better version of fbDebugger.
Does something like that will suit you? (example made with a spreadsheet)St_W wrote:You may remember I requested a feature some time ago which I called "Call stack" (see here), as it is called in popular debuggers for other programming languages. I wasn't able to explain exactly to you, what it should be and behave like.
The context-menu command "Locate calling line" was a first step towards what I had in mind. The new feature you are calling "Backtracking" comes quite close to what I meant when I wanted a "Call stack". It's just a different representation. You can imagine the call stack as a list of all "current" locations seen in the Backtracking dialog when navigating from the current execution procedure up to the most top procedure (in the Backtracking dialog using the "prev" button).
It will be based on a list view and the display can be done in the other way.
The new beta fixes the two bugs described in a previous post :
- for/next loop executed in one step no debugging (gcc version).
- local variables values of main proc are false, issue with their addresses (gcc version).
The Dissassembly is now available in source code tab, proc/var tab and proc tab.
<<<Link removed.>>>
For now after adding the St_W's request, I have to insert freebasic code inside the asm code (proc dissassembly).
.
Last edited by SARG on Aug 31, 2013 22:08, edited 1 time in total.
Re: FB debugger : 2.70 BETA 3 (august 27, 2013)
Thank you for your quick response - that looks fine. I just want to show you how this looks in Visual Studio (2010; sorry - I had only a german localized version installed) for comparison. VS also can show calls outside of the application binary (i.e. kernel32.dll) and tries to determine the stack frames for binaries, where no debug symbols are loaded (no debug information available; lines in grey). Which values are displayed is configurable using the context-menu.
The stack view of GNU Insight (GDB GUI) is very simple - only function names - see http://sourceware.org/insight/screenshots.php.
I think your suggestion to separate filename, function name/address and calling line/address is even better than the VS approach.
Now to the functional part. When activating a certain Stack frame usually not only the cursor jumps to the location in source code, but - as the name tells - it allows navigating through the stack. e.g. when selection a certain stack frame all the local variables of that frame are displayed.
But fbDebugger doesn't need all these features other debuggers provide. A simple list as you've described is perfectly fine. I wanted to show you how other debuggers display that data.
The stack view of GNU Insight (GDB GUI) is very simple - only function names - see http://sourceware.org/insight/screenshots.php.
I think your suggestion to separate filename, function name/address and calling line/address is even better than the VS approach.
Now to the functional part. When activating a certain Stack frame usually not only the cursor jumps to the location in source code, but - as the name tells - it allows navigating through the stack. e.g. when selection a certain stack frame all the local variables of that frame are displayed.
But fbDebugger doesn't need all these features other debuggers provide. A simple list as you've described is perfectly fine. I wanted to show you how other debuggers display that data.
Re: FB debugger : 2.70 BETA 3 (august 27, 2013)
So I'll keep the display format with three columns. When the user clicks on the left column (a bit more complicated determining the row when clicking on an other column) the calling line is displayed and highlighted. And icing on the cake (in France we prefer cherry on the cake....) the local variables of the involved proc are also shown in proc/var tab.St_W wrote:I think your suggestion to separate filename, function name/address and calling line/address is even better than the VS approach.
Now to the functional part. When activating a certain Stack frame usually not only the cursor jumps to the location in source code, but - as the name tells - it allows navigating through the stack. e.g. when selection a certain stack frame all the local variables of that frame are displayed.
Even if It was possible to navigate outside of the debuggee I don't see any interest ;-)
What is better : the first call at top and the last one at bottom or the inverse ? Anyway this can be configurable.
FBdebugger should be the best :-) I think add this feature quickly.St_W wrote:But fbDebugger doesn't need all these features other debuggers provide. A simple list as you've described is perfectly fine. I wanted to show you how other debuggers display that data.
Re: FB debugger : 2.70 BETA 3 (august 27, 2013)
Probably there is no "best" way, but I would put the innermost frame on top and the outermost frame on bottom, like Visual Studio, Eclipse and Xcode (as far I've seen on screenshots) - but unlike Insight, which places the outermost frame on top and the innermost frame on bottom.SARG wrote:What is better : the first call at top and the last one at bottom or the inverse ? Anyway this can be configurable.
I think FBdebugger is already the best debugger available for FreeBasic on Windows. One can't really compare it with other debuggers, which often support multiple programming languages. And at one point FBdebugger is better than every other debugger I know: support by the developer in form of general help, implementation of feature requests, finding/fixing bugs, and so on .. :-) Big thanks again for your great work!SARG wrote:FBdebugger should be the best :-) I think add this feature quickly.
Re: FB debugger : 2.70 BETA 4 (august 31, 2013)
That's enough.... Thanks. ;-)St_W wrote:I think FBdebugger is already the best debugger available for FreeBasic on Windows. One can't really compare it with other debuggers, which often support multiple programming languages. And at one point FBdebugger is better than every other debugger I know: support by the developer in form of general help, implementation of feature requests, finding/fixing bugs, and so on .. :-) Big thanks again for your great work!
Still a new beta (4).
The feature suggested by St_W to follow the proc calls is now implemented. I call it "Proc call chaining" but any better name are welcome.
See the screenshot. The option exists also in the context menu of thread tab.
Every proc for a thread is listed. the proc selected at the beginning is highlighted.
Click on one line to jump on the calling line in the source code and at the same time the proc is selected and its variables are expanded (one level) in the proc/var tab. All the other procs are collapsed. The listview is sized to suit the number of procs, up to 10. Beyond, scrolling is required. The column sizes can be increased in the next version if needed.
The Proc call backtracking is kept.
version 2.70 Beta 4
I have done the inverse, more easy. By Clicking on the top of the listview, just a message is displayed but I can add the possibility to toggle the order.St_W wrote:Probably there is no "best" way, but I would put the innermost frame on top and the outermost frame on bottom, like Visual Studio, Eclipse and Xcode (as far I've seen on screenshots) - but unlike Insight, which places the outermost frame on top and the innermost frame on bottom.SARG wrote:What is better : the first call at top and the last one at bottom or the inverse ? Anyway this can be configurable.
.
Fbdebugger : 2.70
Hi all,
A new version, see first post for details and the link for downloading.
The main new features :
- fully (I hope) support of gcc option. See the known issues.
- Backtracking and calling chain to follow the calling/called procs.
- Dissassembly of one line or one proc.
To come :
- Many internal changes due to 64 bit :-(
- hardware breakpoint : this gives the possibility to stop the debuggee when a specific area in memory is read or written
- use of dwarf debugging data : now with the gcc option and mainly in the future for the 64 bit version of fbc. Stabs data can not be used but anyway I will check that.
As the exploitation of dward data is a lot more complicated fbdebugger uses the objdump tool to decode them.....
A new version, see first post for details and the link for downloading.
The main new features :
- fully (I hope) support of gcc option. See the known issues.
- Backtracking and calling chain to follow the calling/called procs.
- Dissassembly of one line or one proc.
To come :
- Many internal changes due to 64 bit :-(
- hardware breakpoint : this gives the possibility to stop the debuggee when a specific area in memory is read or written
- use of dwarf debugging data : now with the gcc option and mainly in the future for the 64 bit version of fbc. Stabs data can not be used but anyway I will check that.
As the exploitation of dward data is a lot more complicated fbdebugger uses the objdump tool to decode them.....
Re: Fbdebugger : 2.70
Link Fbdebugger 2.70 is truncated in your first post.SARG wrote:A new version, see first post for details and the link for downloading.
Complete link:
http://users.freebasic-portal.de/sarg/f ... _09_29.zip
[Edit]
The link is now fixed!
Last edited by fxm on Sep 30, 2013 16:43, edited 1 time in total.
Re: Fbdebugger : 2.70
Link fixed.fxm wrote:Link Fbdebugger 2.70 is truncated in your first post.SARG wrote:A new version, see first post for details and the link for downloading.
Complete link:
http://users.freebasic-portal.de/sarg/f ... _09_29.zip
Thanks.
Re: FB debugger : 2.70 (september 29th, 2013)
I've just spotted this :
http://arduino.cc/en/ArduinoCertified/IntelGalileo
The operating system and boot details are vague, but I could see instantly that a remote-debug version of FB debugger would be great here.
Perhaps intel will release enough info, to allow one to be built ?
Looks like they have a USB connector for programming.
http://arduino.cc/en/ArduinoCertified/IntelGalileo
The operating system and boot details are vague, but I could see instantly that a remote-debug version of FB debugger would be great here.
Perhaps intel will release enough info, to allow one to be built ?
Looks like they have a USB connector for programming.
-
- Posts: 9
- Joined: Oct 23, 2013 19:12
Re: FB debugger : 2.70 (september 29th, 2013)
Hello SARG,
Thanks you for the recent version of the FB Debugger. After working with it a bit, I notice that the debugger doesn't load all the files into the program. In my case, the "Def.bi" file which contains most of the file type and structures for the program was not included (non-executables files perhaps?) However, when debugging I cannot watch these structures or see their contents to figure out my error.
Is there a way to load them (BI sources) into the debugger and have it be recognized?
Thanks,
CD
Thanks you for the recent version of the FB Debugger. After working with it a bit, I notice that the debugger doesn't load all the files into the program. In my case, the "Def.bi" file which contains most of the file type and structures for the program was not included (non-executables files perhaps?) However, when debugging I cannot watch these structures or see their contents to figure out my error.
Is there a way to load them (BI sources) into the debugger and have it be recognized?
Thanks,
CD
Re: FB debugger : 2.70 (september 29th, 2013)
Hi,
Edit.
Using an include file like below it works : the file is displayed. Just add sub dummy:end sub.
BUT the line with the print is considered as not executable. However the var testinc2 is listed in the proc/var tab.
You're welcome.ChesterDennis wrote:Thanks you for the recent version of the FB Debugger.
I guess it's an issue (already reported) with the debugging data in fbc : if included files don't contain any proc the main file name is used instead their file name.ChesterDennis wrote:After working with it a bit, I notice that the debugger doesn't load all the files into the program. In my case, the "Def.bi" file which contains most of the file type and structures for the program was not included (non-executables files perhaps?)
This problem is not related to the previous one as the data for structure/var/ etc are independant from those about line numbers and file names. Could you post a small example it will be easier to understand what happens. :-)ChesterDennis wrote:However, when debugging I cannot watch these structures or see their contents to figure out my error.
The only way, I think, is to put a dummy proc in your def file and perhaps you may also need to add a call to it somewhere. Not tested, I'll try later......ChesterDennis wrote:Is there a way to load them (BI sources) into the debugger and have it be recognized?
Edit.
Using an include file like below it works : the file is displayed. Just add sub dummy:end sub.
BUT the line with the print is considered as not executable. However the var testinc2 is listed in the proc/var tab.
Code: Select all
Sub dummy:End Sub
Dim As Integer testinc2=17
print "inside testinc2 ";testinc2
-
- Posts: 9
- Joined: Oct 23, 2013 19:12
Re: FB debugger : 2.70 (september 29th, 2013)
Hi SARG,SARG wrote:Hi,
You're welcome.ChesterDennis wrote:Thanks you for the recent version of the FB Debugger.
I guess it's an issue (already reported) with the debugging data in fbc : if included files don't contain any proc the main file name is used instead their file name.ChesterDennis wrote:After working with it a bit, I notice that the debugger doesn't load all the files into the program. In my case, the "Def.bi" file which contains most of the file type and structures for the program was not included (non-executables files perhaps?)
This problem is not related to the previous one as the data for structure/var/ etc are independant from those about line numbers and file names. Could you post a small example it will be easier to understand what happens. :-)ChesterDennis wrote:However, when debugging I cannot watch these structures or see their contents to figure out my error.
The only way, I think, is to put a dummy proc in your def file and perhaps you may also need to add a call to it somewhere. Not tested, I'll try later......ChesterDennis wrote:Is there a way to load them (BI sources) into the debugger and have it be recognized?
Edit.
Using an include file like below it works : the file is displayed. Just add sub dummy:end sub.
BUT the line with the print is considered as not executable. However the var testinc2 is listed in the proc/var tab.Code: Select all
Sub dummy:End Sub Dim As Integer testinc2=17 print "inside testinc2 ";testinc2
Your dummy sub trick worked - the .BI file is now loaded. Thanks.
Now, the question of getting access to the variable/data:
How do I get to the various indexes of game.tableau(i).currcard? The debugger tells me that it's not a running variable.
This whole exercise started when I noticed an error in one of the FB games (golfsol) and wanted to investigate so that I could fix it (just to get a feel of what FreeBasic was all about).
CD
Re: FB debugger : 2.70 (september 29th, 2013)
1/ In proc/var tab select the item where the index(es) is (are) listed (here TABLEAU)ChesterDennis wrote:How do I get to the various indexes of game.tableau(i).currcard? The debugger tells me that it's not a running variable.
2/ in the context menu (right click) select the option 'Select index'
3/ select the value you want (directly or by the buttons +/-)
4/ click on 'Apply'
The value near the bounds (current index) is changed showing the new current index and the value of every element of the structure is also changed.
-
- Posts: 9
- Joined: Oct 23, 2013 19:12
Re: FB debugger : 2.70 (september 29th, 2013)
Hi SARG,SARG wrote:1/ In proc/var tab select the item where the index(es) is (are) listed (here TABLEAU)ChesterDennis wrote:How do I get to the various indexes of game.tableau(i).currcard? The debugger tells me that it's not a running variable.
2/ in the context menu (right click) select the option 'Select index'
3/ select the value you want (directly or by the buttons +/-)
4/ click on 'Apply'
The value near the bounds (current index) is changed showing the new current index and the value of every element of the structure is also changed.
Not matter what I try I get the same error: "[Variable Selection Error]: Select only a variable."
CD