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.
Related
After running and completing any command in the terminal I would like to have a --------------------- added on a new line to make it easier to find where I started older commands.
I often have a hard time scrolling back to see where exactly a call was made, and having a line break would help a lot.
Thanks!
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.
When I am in a shell like bash, if I use the up arrow to go through the command-line-history buffer, it behaves in a predictable way: hitting up goes to the command I executed most recently.
In the Windows cmd.exe ("DOS") shell, sometimes hitting the up arrow goes to the most recent command, sometimes it goes to the 2nd most recent command or even the 3rd most recent command. Sometimes, to get to the most recent command I entered, I actually have to hit the down arrow! Sometimes I have to hit the down arrow twice!
What is the logic to this? It's been driving me batty for a long time.
The command selected by up/down-arrow is relative to the last-selected repeat.
So if you have executed
line 1
line 2
line 3
line 4
Then pressing up-arrow 3 times and enter would reselect and execute line 2
From there, you can down-arrow once to re-select line 3 or twice for line 4 or up-arrow once for line 2, twice for line 1
BUT the new lines executed are appended to the list and if you enter a line manually, the selector moves to the bottom of the list again.
The line will not be entered into the list if it is a duplicate of the last entry, so you can up-arrow-and-execute a thousand times if you want to and up-arrow-twice will get the (-1001st) command entered.
Is it possible to jump to current line being executed in the Source Window of cgdb?
It would be great to have a command or a shortcut to do this, especially after browsing files in the File Dialog mode for a long time.
It turned out that you can jump to current line easily: just use gdb frame command without arguments, or simply f.
I don't think we have a shortcut for it. I usually do a quick up and down (or vice versa) in gdb.
You can use '.. Please please See https://github.com/cgdb/cgdb/issues/53
When debugging a function (which has been marked debug using debug("f"), the debugger gives you the Browser prompt which also tells you at what line number in the program you are. If run a couple of test statements at the prompt (to check variables, etc.) the screen scrolls and I no longer know what line number I am at (using SecureCRT so it scrolls past the buffer). The command where only tells you what function you are in. Does anyone know how to get the actual line number and next statement to be executed?
Thanks
When I use the regular browser(), I set max.lines to print to a low number:
options(deparse.max.lines=100)
so that if the output during debugging is long, I don't have to scroll too far up.