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

[St_W]

@TJF: Thanks for your answer, but the the same problem still exists. No matter what piece of non-executable assembler code I insert. I've tried comments (see above; my previous post), labels and TJF's suggestion (I've no idea what this directive is/means?)

Example (works):

Code: Select all

Dim a As UInteger = 1
Dim b As UInteger = 2

'ASM begintest = .

Asm
	mov eax, [a]
	mov [b], eax
End Asm
b = a

'ASM endtest = .

/'Asm begintest2:

a = b

Asm endtest2:'/

Print a

Sleep

When uncommenting one non-executable asm statement the debugger seems to skip one statement (no output printed to console in the example above). When uncommenting two such statements the debuggee hangs. Using normal (executable) inline assembler statements works just fine.

[TJF]

First of all: sorry, I'm just guessing. (I've neither a windows nor a FB debugger installation to test.)

Using normal (executable) inline assembler statements works just fine.

This makes me wonder. My proposals are executable inline assembler statements ?!?

[SARG]

Hi all,

Finally I have an access so I'm able to reply.

Excellent! Good add-on. While the lights are not for all words, not for (endif, with and may have any).

Thanks. You can add some words (before I finish) in the line_change function....

1) I then tried to debug the application is Unicode, but it looks like the debugger does not know how to work with Unicode?

Not tried.

2) I have not found ... The debugger can debug multithreaded applications?

Yes fbdebugger is ready for debugging with more than one thread but not a lot of tests. I guess you'll encounter some bugs
See in tab thread to select the thread you want to be executed.

first I have to say that your debugger is a great piece of software and thank your effort you have put into this.

Thanks.

I wonder whether this is a problem of your debugger or fbc (as generating STABS info) and if there's a solution.

The both : as there is no code in the asm, the comment line and the next instruction have the same adress......


Near line 6080, Just add this test, don't forget to remove 'linenb+=1' in the line after endif :

Code: Select all

        	case 68
        		'And recupstab.nline>lastline    : To avoid very last line see next comment about lastline
        		'recupstab.nline<>65535 And 
            if procnodll And flagstabd And recupstab.nline>lastline Then
            	'asm with just comment 25/06/2012
               If recupstab.ad+proc2<>rline(linenb).ad Then 
               	linenb+=1
               Else 
               	WriteProcessMemory(dbghand,Cast(LPVOID,rline(linenb).ad),@rLine(linenb).sv,1,0)
               EndIf
               rline(linenb).ad=recupstab.ad+proc2:rLine(linenb).nu=recupstab.nline:rLine(linenb).pr=procnb
               ' 25/06/2012

Tested only with your code, you should try with more complex codes.

.

[St_W]

Hi SARG,

when I'm trying to debug FreeBASIC code, that is compiled as a static library and linked to a dynamic library which is itself loaded by an executable, I can't set breakpoints or step through the code.

I've compiled a little demo project for you so that you can easier test and understand what i mean.

It contains three .bas files:
main.bas is the main executable
lib.bas is the static library that is linked to the dynamic library below
dll.bas is the dynamic library that "contains" the static library above

Using fbDebugger 2.6 beta 8 i can single step and set breakpoints in main.bas and dll.bas, but not in lib.bas - although all three source files are loaded in the debugger.

I would really like to debug this linked static libs - it would make many things easier. Is that possible / feasible in a reasonable period of time?

Other minor problems/unexpected behaviour I've detected:
- the same source files are opened twice probably because i'm loading and unloading the dll twice; but that probably doesn't make sense.
- the dll is still loaded/in use by fbdebugger after the debuggee has terminated.

Many thanks once again for your great debugger.

[SARG]

Hi St_W,

I would really like to debug this linked static libs - it would make many things easier. Is that possible / feasible in a reasonable period of time?

You found a bug, I tested dll and lib but not the case of lib in dll. So thanks for the reporting and now quickly the solution.

In the extractstabs proc just add the marked line (>>>)

Code: Select all

       select case recupstab.code
        	case 36 'proc
                       procnodll=FALSE
                       procnmt=cutup_proc(left(recup,instr(recup,":")-1))
>>>>  If procnmt="main" Then flagstabd=TRUE 
                       If procnmt<>"" and procnmt<>"{MODLEVEL}" and(flagmain=TRUE Or procnmt<>"main") Then

By the way, did the previous modification solve your asm problem ?

- the same source files are opened twice probably because i'm loading and unloading the dll twice; but that probably doesn't make sense.

known issue : corresponding source tabs are not freed when dll are unloaded. I have to work on this.

- the dll is still loaded/in use by fbdebugger after the debuggee has terminated.

To check and find a fix.

I hope to release next week a version with a lot of new features (highighted keywords, background and lines colors, break on var for strings, better taking in account of variables with gcc...) .

[St_W]

You found a bug, I tested dll and lib but not the case of lib in dll. So thanks for the reporting and now quickly the solution.

Thanks for your really quick answer and fix. Works like a charm!

By the way, did the previous modification solve your asm problem ?

I did replace the asm piece of code later, but as far as I've tested it solved the problem.

I hope to release next week a version with a lot of new features (highighted keywords, background and lines colors, break on var for strings, better taking in account of variables with gcc...) .

I'm looking forward to see an even better version of FB debugger.

Again some other thoughts:
In the "dll-debugging.zip" sample above a shared variable "b" exists both in main.bas and lib.bas, but FB debugger only shows the one from main.bas.

btw. can FB debugger show the call stack?

[SARG]

Thanks for your really quick answer and fix. Works like a charm!
I did replace the asm piece of code later, but as far as I've tested it solved the problem.

Good news ;-)

Again some other thoughts:
In the "dll-debugging.zip" sample above a shared variable "b" exists both in main.bas and lib.bas, but FB debugger only shows the one from main.bas.

Seems not difficult to fix, I'll do it quickly.

btw. can FB debugger show the call stack?

Could you please clarify what you want.

[St_W]

btw. can FB debugger show the call stack?

Could you please clarify what you want.

For example, Visual Studio 2012 RTM:

To put it simple, it's a list of called subroutines - the current subroutine on top and the callers below - and one can navigate to the callers by double clicking in the list.

What I also did miss/not find in fb Debugger yesterday was jumping to a certain address in the process memory. I could jump to addresses where variables referred to, but not custom addresses.

[SARG]

To put it simple, it's a list of called subroutines - the current subroutine on top and the callers below - and one can navigate to the callers by double clicking in the list.

Ok, understood. As the flow of called procs is kept I guess it could be possible. let me some time ;-)
Just one point, what do you mean by "navigate" ?

What I also did miss/not find in fb Debugger yesterday was jumping to a certain address in the process memory. I could jump to addresses where variables referred to, but not custom addresses.

Click on the "M" button then right click and input a "valid" address (otherwise you get an error message). You can also choice the format of the display (integer, byte, etc). Now move inside the memory using these buttons "+" or "-" = one line , "++" or "--" = one page.

[St_W]

Ok, understood. As the flow of called procs is kept I guess it could be possible. let me some time ;-)
Just one point, what do you mean by "navigate" ?

I meant only that you can jump (in terms of viewing; no changes to the running program or anything like that) to the calling location (or, to be exact, the statement after the call in visual studio) in the source file.
Visual studio can display the disassembly if it doesn't have source, but that isn't necessary and probably would be an overkill for your project. If it doesn't have debug symbols (debug info; stabs in our case) it cant display all the stack frames, because it doesn't know the stack-frame size. http://en.wikibooks.org/wiki/X86_Disass ... ack_Frames

Thanks for your description how to jump to a memory location in dump. I'll try when I'm at home in a few hours.

[SARG]

Hi all,

I have still to update the help file but now a new version of fbdebugger with some interesting features.

http://jafile.com/uploads/sarg/fbdebugg ... eta_16.bas

Thank you to Mod, St_W, Enform, AGS
Added
- wrapping/no wrapping for the "Show String" Window (proc/var context menu)
- choice of font including size, saved in the ini file (settings)
- highlighted keywords (settings)
- choice of the color for background and lines (current/breakpoint), saved in the ini file (settings)
- strings (except wstring) can now be used with break on var, 25 char max
- new option "focus line" (shortkey L) in the source window opens a window to follow the executed line or an other part of any source module. This window hasn't the horizontal scrolling style.(proc/var context menu)
- double set watch var with/without trace (proc/var context menu)
- exchange between Byte And ZString type to fix the fact that with gcc the zstring are stored as byte array (proc/var context menu)
- locate the line (calling line) where a proc has been called (proc/var context menu)
For an easy use, collapse the treeview to see only the procs and display a sort of call stack
- option "show executable lines" has been replace by "mark no executable lines", the lines are displayed in green (proc/var context menu)

Fixed
- issue when comments are used in asm lines
- no access in the libs used in a dll
- better support of -gen gcc option : the management of variables except some should be correct.
In fact Fbdebugger translates the gcc data stabs in the old form (-gen gas) before use.
Sometimes there are issues with line numbers I'm not sure that it could be easily fixed.

@St_W the issue with shared var used in dll/lib is more complicated that I thought so no fix for now :-(

WARNINGS
- if the version of gcc is > 3, add this parameter -Wc -gstabs+ in the FBC command-line in addition of -g otherwise the stab datas are not added
- With FBC 0.24 FBdebugger crashs (Window message) when the debuggee is terminated, that didn't happen with 0.23 ???.
Using the -exx fbdebugger also stops but without an information about the problem and no Window message.
I have to look further into the issue but any help is welcome.

[VANYA]

Hi SARG!

- With FBC 0.24 FBdebugger crashs (Window message) when the debuggee is terminated, that didn't happen with 0.23 ???.
Using the -exx fbdebugger also stops but without an information about the problem and no Window message.
I have to look further into the issue but any help is welcome.

Yes, confirm the program takes off.

I tried FB 0.24 and an older version of the debugger:

http://s50.radikal.ru/i129/1209/e9/400c4a6053b6.png

Not crashed!

[SARG]

@VANYA,

Compile FBdebugger with FBC 0.24 and launch it. Then run any test program compiled with FBC 0.24 or an older version.
FBdebugger crashs when the debuggee is terminated normally or by killing.

If you compile Fbdebugger with FBC 0.23 you should not get this behaviour.

Strangely if you don't close the "crash Window message" you can continue to use FBdebugger --> the problem seems happening in a Window's subroutine.

[VANYA]

@VANYA,

Compile FBdebugger with FBC 0.24 and launch it. Then run any test program compiled with FBC 0.24 or an older version.
FBdebugger crashs when the debuggee is terminated normally or by killing.

If you compile Fbdebugger with FBC 0.23 you should not get this behaviour.

Strangely if you don't close the "crash Window message" you can continue to use FBdebugger --> the problem seems happening in a Window's subroutine.

SARG! I think I understand what the problem is. I myself came across like that in my program. You have the code of procedure:

dbg_attach () and start_pgm () are no parameters. And this is in version 0.24 can not be done!

Rightly so:

dbg_attach( p as Any ptr) and start_pgm(p as Any ptr)

[SARG]

SARG! I think I understand what the problem is. I myself came across like that in my program. You have the code of procedure:
dbg_attach () and start_pgm () are no parameters. And this is in version 0.24 can not be done!
Rightly so:
dbg_attach( p as Any ptr) and start_pgm(p as Any ptr)

Ok many thanks, it was the problem. All works right now.

I can release the 2.60 version.