debugger in visual c++
-
Hi I am a newbie to programming and would like to ask a question regarding the debugger. Sometimes when I step into a function the assembler comes up. Why is this? :confused: And how do I get around it quickly? I find that by stepping out many many times eventually takes me back to the code where the assembler 1st appeared. Thank you for any information.
-
Hi I am a newbie to programming and would like to ask a question regarding the debugger. Sometimes when I step into a function the assembler comes up. Why is this? :confused: And how do I get around it quickly? I find that by stepping out many many times eventually takes me back to the code where the assembler 1st appeared. Thank you for any information.
Here is how in general a debugger workds: When you build your application in debug mode the executables and/or dlls (or other library files) contain a lot of extra information on top of the actual code. That information are like hyper links to the source C code. Imagine like saying "the following ten assembly commands are in that line of that cpp file". The debuger, in order to display you the source code, it needs the extra 'debug' information and access to the cpp source file. When the debuger cannot find the source code it displays what it runs in assembly. If you are an assembly guru you might be able to debug the application with that. The usual reasons that goes to assembly are: i. The application or parts of it are not build in debug mode. Thus, the debuger has no clue where the source is. ii. The function you step in belongs to the compiler libraries. No company will give you the source C code of them so stepping into them means you go into assembly. iii. You haven't informed your debuger where the C source code is. Perhaps that has to do with the project settings etc.
-
Here is how in general a debugger workds: When you build your application in debug mode the executables and/or dlls (or other library files) contain a lot of extra information on top of the actual code. That information are like hyper links to the source C code. Imagine like saying "the following ten assembly commands are in that line of that cpp file". The debuger, in order to display you the source code, it needs the extra 'debug' information and access to the cpp source file. When the debuger cannot find the source code it displays what it runs in assembly. If you are an assembly guru you might be able to debug the application with that. The usual reasons that goes to assembly are: i. The application or parts of it are not build in debug mode. Thus, the debuger has no clue where the source is. ii. The function you step in belongs to the compiler libraries. No company will give you the source C code of them so stepping into them means you go into assembly. iii. You haven't informed your debuger where the C source code is. Perhaps that has to do with the project settings etc.
Thanks for the information on why the assembler pops up. I was also wondering on how to exit out of it? I mentioned before that I could step out many many times and eventually it will return to the src code. I was wondering if there is a quicker methods than this? Am I right in saying that you can step out and then immediately close the assembler to return to the src code? Thanks for your time.
-
Thanks for the information on why the assembler pops up. I was also wondering on how to exit out of it? I mentioned before that I could step out many many times and eventually it will return to the src code. I was wondering if there is a quicker methods than this? Am I right in saying that you can step out and then immediately close the assembler to return to the src code? Thanks for your time.
Well by pressing Shift-F11 returns to the caller. I found the usually this works. Another trick is to use the variables debug window. The context list box contains the stack of the functions. You can see where in the code are you in any depth. Select the level that you 're interested and put a break point immediately after the current step. Then press F5 (run into cursor) to bring you there. However, the best way is to know where not to step into. If your application is propery build in debug mode try not to step into functions that you do not recognise and especially those that they are known library functions (like printf, calloc etc.) Note that for some MFC classes/functions microsoft provides the source codeto assist you seeing the bug. You will know that by the name of the file that the debuger opens.
-
Well by pressing Shift-F11 returns to the caller. I found the usually this works. Another trick is to use the variables debug window. The context list box contains the stack of the functions. You can see where in the code are you in any depth. Select the level that you 're interested and put a break point immediately after the current step. Then press F5 (run into cursor) to bring you there. However, the best way is to know where not to step into. If your application is propery build in debug mode try not to step into functions that you do not recognise and especially those that they are known library functions (like printf, calloc etc.) Note that for some MFC classes/functions microsoft provides the source codeto assist you seeing the bug. You will know that by the name of the file that the debuger opens.
Thank you for your advice. Unfortantely my application is 600,000+ lines and is difficult to know what does what without experimenting so I will use your two first points. But I still find that using SHIFT + F11 does'nt always get you out of the disassembly? Am I doing something wrong with that? Am I right in saying that it should return you to the source immediately? Thanks again for your tips. ;)
-
Thank you for your advice. Unfortantely my application is 600,000+ lines and is difficult to know what does what without experimenting so I will use your two first points. But I still find that using SHIFT + F11 does'nt always get you out of the disassembly? Am I doing something wrong with that? Am I right in saying that it should return you to the source immediately? Thanks again for your tips. ;)
Shift-F11 is technically step return which means that it will return to the caller. Sometimes the caller is not directly your source but something else in assembly (perhaps parameters etc). Also I am strongly suspect that your application is not completely build in debug mode. My hint is try not to enter into assembly (if you can) and make sure that all 600,000 are build in debug mode. If they are sometimes you should be able to see as assembly comments the source C lines. If so then try to see why the debuger cannot find the actual source file. Do you point it to them properly?
-
Shift-F11 is technically step return which means that it will return to the caller. Sometimes the caller is not directly your source but something else in assembly (perhaps parameters etc). Also I am strongly suspect that your application is not completely build in debug mode. My hint is try not to enter into assembly (if you can) and make sure that all 600,000 are build in debug mode. If they are sometimes you should be able to see as assembly comments the source C lines. If so then try to see why the debuger cannot find the actual source file. Do you point it to them properly?
Hello I went to build -> configurations and made sure the 'debug' version was selected. I then pressed F7 to build a debug version of the project. I then started the application by selecting Go (F5). The application seems to behave itself more when the assembler pops up in that by pressing SHIFT + F11 (step out) it returns to the source. I guess I must have chosen the wrong build or something which is why it was'nt properly working when I tried to step out of the assembler. But Thanks for your advice. :-D