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
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
This makes me wonder. My proposals are executable inline assembler statements ?!?St_W wrote:Using normal (executable) inline assembler statements works just fine.
Thanks. You can add some words (before I finish) in the line_change function....VANYA wrote: Excellent! Good add-on. While the lights are not for all words, not for (endif, with and may have any).
Not tried.VANYA wrote: 1) I then tried to debug the application is Unicode, but it looks like the debugger does not know how to work with Unicode?
Yes fbdebugger is ready for debugging with more than one thread but not a lot of tests. I guess you'll encounter some bugsVANYA wrote: 2) I have not found ... The debugger can debug multithreaded applications?
Thanks.St_W wrote: first I have to say that your debugger is a great piece of software and thank your effort you have put into this.
The both : as there is no code in the asm, the comment line and the next instruction have the same adress......St_W wrote: I wonder whether this is a problem of your debugger or fbc (as generating STABS info) and if there's a solution.
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
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.St_W wrote: 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?
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
known issue : corresponding source tabs are not freed when dll are unloaded. I have to work on this.St_W wrote: - the same source files are opened twice probably because i'm loading and unloading the dll twice; but that probably doesn't make sense.
To check and find a fix.St_W wrote: - the dll is still loaded/in use by fbdebugger after the debuggee has terminated.
Thanks for your really quick answer and fix. Works like a charm!SARG wrote: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.
I did replace the asm piece of code later, but as far as I've tested it solved the problem.SARG wrote:By the way, did the previous modification solve your asm problem ?
I'm looking forward to see an even better version of FB debugger.SARG wrote: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...) .
Good news ;-)St_W wrote: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.
Seems not difficult to fix, I'll do it quickly.St_W wrote: 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.
Could you please clarify what you want.St_W wrote:btw. can FB debugger show the call stack?
For example, Visual Studio 2012 RTM:SARG wrote:Could you please clarify what you want.St_W wrote:btw. can FB debugger show the call stack?
Ok, understood. As the flow of called procs is kept I guess it could be possible. let me some time ;-)St_W wrote: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.
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 wrote: 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.
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.SARG wrote: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" ?
Yes, confirm the program takes off.SARG wrote:- 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.
SARG wrote:@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.
Ok many thanks, it was the problem. All works right now.VANYA wrote:
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)