I want to use the option of "step into" in the debugger. But, I want that the debugger enters only function that are implemented in specific files. For other functions, "step into" will behave like "Step Over".
You can use the debuggers stepping configuration to define where you want the debugger to stop and where not.
Or you can put a breakpoint to a start point from where you want to examine the behavior of your code and then put breakpoints in your specific files/implementations.
Furthermore, it would be very helpful if you describe your problem in more detail.
Related
So I am using Qt Creator with LLDB as debugger.
To debug stuff I add breakpoints and when the code hits the breakpoint it stops and I can see the back trace and all and that's useful. However, sometimes I don't want to stop and I am only interested in whether the breakpoint is hit, or I want to inspect a value there.
I usually do this with adding debugging messages but that generally takes a lot of time to recompile the project and rerun the scenario.
I'm wondering is there a better way to do this, using a debugger, preferably LLDB.
All the break set commands take a --auto-continue option (one-letter: -G) that will instruct lldb to continue after stopping for the breakpoint (and running any of its commands).
You can run lldb commands when a breakpoint is hit (e.g. to do a backtrace or print some locals) using the break command add command or by adding any number of -C options to the break set command. You can also add a Python implemented callback to the breakpoint as described here:
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
if you need to do something fancier to gather your report when you hit the breakpoint.
If you want to edit currently active break point you can do the following:
breakpoint modify <break_point_id> -G true
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
Every so often, when I'm debugging and stepping through a thread, Xcode pulls me into another thread (that I'm guessing is executing all the other stuff involved in setting up views etc.). the problem is that this doesn't help me, as I just want to observe the code I've written myself.
Is there any way to prevent this?
If you use "step over" you normally won't see this view, I only ever see it when I do "step into" on lines with a compound statement.
What you are seeing is not your code, but the debugger working through code it doesn't have the source to (e.g. UIKit stuff). If you hit "step out" or "step over" in this view, you will return to your code.
Usually, this works, but in addition to my own code there a lot of machine code too, which doesn't really help me out with debugging my own program logic.
Is there a way to step through only my own code?
First put a breakpoint where you want to start step over.After the breakpoint ,Use this button to step over through the code.The play button just runs till the next breakpoint
You probably want to be using the next command or "step over" button in the debugger UI instead of step or "step into" to avoid stepping into each function as you debug. You might still want to step into your own functions, of course, but next will let you step over framework functions instead of diving into their assembly.
I like how you can capture breakpoints as Intellitrace events. Breakpoints are easy to add/enable/disable, and can be added/removed at runtime (as opposed to say Console events).
However, of course breakpoints stop the flow of execution, and I have to press F5 F5 F5 F5 F5 F5 constantly while I debug the running application. I'd love to be able to capture breakpoint events in intellitrace and just let the code execute without actually breaking on the breakpoints.
I've also used Console statements as captured intellitrace events, but breakpoints are much easier to add (F9 as opposed to pasting a Console.WriteLine("...") everywhere), and I can add and disable new breakpoints at runtime, whereas if I want to add or remove a Console based event at runtime, I have to stop the program, add/delete, and restart.
Are there any good ways to capture intellitrace events in this way?
I think this is what you are looking for:
http://geekswithblogs.net/sdorman/archive/2009/02/14/visual-studio-2008-debugging-tricks-ndash-advanced-breakpoints.aspx
Basically, you can use an advanced breakpoint to do a number of different things. In your case, you would probably want to use the tracepoint that simply gives a hit count. In other cases, you might want to specify that the breakpoint only occurs after a certain number of hits (maybe you want to be sure a loop isn't infinite).
Visual Studio has a ton of great features inside of the breakpoint option. I'm sure that even if the above option didn't solve your problem that there is still something that is included in the above article that will solve your problem.