When executing next [count] or step [count] (e.g. next 10) in GDB, is there any way to display each line that gets executed, as if you had entered next or step [count] times?
I know that I can execute next once and then hold down the enter key for a while, but it's hard to precisely control where to stop when you do this.
gdb doesn't have a built-in way to do this.
You can do it by hand by writing a loop. This could be done from the CLI by using the define command to make a new command, like verbose-next that invokes next in a loop. Or, you could write it in Python; though in this case there's no particular advantage to doing so.
Related
What command/keyword is used to check for keyboard input without stopping execution? I want to build a loop that will run continuously, and at every iteration of the loop, I want to check for keyboard input. If the user presses the right key, my program will act on it; if not, it will continue to run.
EDIT
I want it to work with out pressing the enter key. Like when a game runs it checks if the user presses the arrow key then acts on the key press or continues if nothing is pressed.
From what I could find and some hacking around, I managed to put together something that will immediately echo the keys you press when running in command line.
require 'io/console'
loop do
p STDIN.getch
end
But as the referenced answer mentions, you'll want to capture SIGTERMs so you don't get trapped in the program: Signal.trap("INT") { exit }
So the meat of your program and all of its processing lives in that main loop, and each go around of that loop it will grab a character from the STDIN.
You cannot do that with a simple method. The most common way to do that is to use the curses gem.
You can easily set a watchpoint in XCode by following these steps (btw if there is a simpler way, I'd like to know it...):
- Run your program
- Set a breakpoint in the code where your variable is used
- when reaching breakpoint, use a right click on the variable and select 'Watch "nameOfTheVariable"'
- Continue execution.
The only problem is that execution will stop every time the variable value changes. I would like XCode to continue the execution without stopping, i.e. merely display the value changes in the console output.
This feature seems available in command line mode, and although I initially wanted to avoid it, I posted a solution using that mode (see below), as it seems to be the only way to do what I want, i.e. continue execution while displaying variable changes.
Well it seems that the only way to achieve this is to use the LLDB command line. So for those of you who, like me, had never used it here is a step-by-step (actually fairly easy) way to use it and watch variables without stopping execution:
Set a breakpoint in Xcode (click to the left of your source line) where the variable you want to watch is used (in scope), and run your code until it reaches the breakpoint.
In the console view (little window displayed at the bottom right where you can display console things) you should see a (lldb) prompt. This is where you enter the following commands:
w s v stuff (or watchpoint set variable stuff) where stuff is the name of the variable you want to watch
w c a (or watchpoint command add) to enter a script mode where you enter one command per line as follows after the '>'
p stuff (or print stuff) to display the new stuff variable value
c (or continue) to continue execution
DONE to finish this little script (note the UPPERCASE characters!)
THAT'S IT ! You can remove your breakpoint and continue execution. From then on messages will be displayed in the console every time the variable "stuff" is updated, without stopping the execution of your code (it might slow it down a little of course, but that is usually not important).
Watchpoint is just like a breakpoint which gets hit when the value of a variable which is being watched gets updated.
To set it please follow below steps:
1.Set a breakpoint such that the variables view in the debugger shows the variable you want to watch.
2.Right click on the variable and select Watch "variable name".
3.This will stop the execution whenever the value of the variable changes.
The watchpoint will now start showing in the debug navigator.
In order to remove it just drag is towards the editor and you are good to go.
PS : this is just a smarter version of implemention didset for a variable and setting and breakpoint inside it.
In GDB it is possible to step multiple instructions with a single command. After much searching, it does not appear to be possible to do the same in LLDB.
For example, in GDB, if you enter si 5, you will step forward 5 instructions. However, doing the same in LLDB results in:
error: Thread index 5 is out of range (valid values are 0 - 1).
In GDB running si with an integer defines how many instructions to step, but in LLDB it defines which thread to step forward 1 instruction.
Is there any way to step forward multiple instructions in LLDB as can be done in GDB?
This is an enhancement that is on our queue, but somehow never makes it to the top. I added a --count option to step-inst & step-next-inst as my lunch time hack. It's in TOT lldb, can't say when it will make it into an official Apple release.
If you're stuck on an older version of LLDB and don't have the feature which was implemented after this question was asked, or simply want to automate repeating any arbitrary commands, here is a quick-and-dirty way of scripting multiple commands which can be entered easily from the interactive LLDB python prompt:
lldb.debugger.SetAsync(False)
for _ in range(3): lldb.debugger.HandleCommand('si')
The above will make the API synchronous, so that each command will complete before running the next, and then loop executing commands (3 times in this example).
To access this prompt, enter the script command at the LLDB prompt, then Python away.
(lldb) script
Does anybody know if it's possible in Test Complete to run a test from a specific point in a function?
I see options like run routine, run test, run project.
Thank you,
Raluca
There is no way to start execution of a script test from a specific line, but it is possible to move the execution point to the desired line. You can set a breakpoint to the first line of a script routine and run this routine. Once the test execution is stopped at the breakpoint, use the Set Next Statement action to move the execution point to the needed line and continue the execution.
This feature is documented in the Setting Next Execution Point help topic.
TestComplete's Keyword Driven Tests have the possibility to add "Labels" and "Go To Labels".
You can put a label anywhere in your KDT script and set a GoToLabel at the very beginning of your test to move to that point.
It may even be possible to combine this with Project Variables to get a "Last Reached Milestone/Label". This is only speculation, but worth looking into it.
no there is no way you can run testcomplete scripts from a specific point. the closest point you can get to for runnning you script from a specific point is to use break point and then press F10 for executing one by one line of code
While debugging some code in gdb, I want to see which line will be executed if I say next or step.
Of course I can say l, but if I say l a couple times (and don't remember how many times), then l does not print the line that will be executed.
I can also scroll back to the last time gdb stopped and see which line it was at, but that sometimes involve digging through a bunch of output.
I am wondering if I am missing a simple command in gdb which shows me the current line the debugger is stopped at?
To see the current line the debugger stopped at, you can use frame command with no arguments. This achieves the same effect as update command. It works both in tui and command line mode.
You can use
list *$eip
or the shorter form
l *$eip
This will instruct gdb to print the source lines near the current program counter.
You can say l +0; the current line will be the first one listed.
The command l +offset lists the code starting from offset lines from the current line.
Note that, if you have already used the list command, the current line will have changed, i.e., it will no longer be the next executing line. So this will only work on your first list command.
It sounds like you want to run GDB in Emacs (which will show you current file and mark the current line), in DDD, or in tui mode.