Is there a way to set a breakpoint at every line in the code with GDB? Obviously I don't want to hit b *addr for every single line, so I'm wondering if there's a fast way to do this.
Edit
Note that I am running a binary created by someone else and I do not have access to the source code. Unfortunately, that binary has not been compiled with the -g flag. Therefore, I cannot just single step through each line in the code.
Further Edit
As Jason points out below, you can indeed single step through the code so long as you use si or ni, as opposed to just simply s (step) or n (next). n or s work fine, though, if the source code had been compiled with -g, but it steps through lines of source code, as opposed to stepping through every assembly instruction like ni or si do in a binary that was compiled without -g.
Use si (stepi) to instruction step through the code. You can use ni (nexti) to step over library functions you're not interested in. If you accidentally step into one of them, finish should get you back to your original routine. People working at this level typically have gdb set to display the next few instructions that are about to be executed, e.g. disp/3i $pc.
Can't you just place the breakpoint on the first line of execution and then step through each line ? This depends on what are you trying to achieve by setting breakpoints on each line. If you want to evaluate expressions, you can do it by following my logic (step through each line).
PowerPC has hardware support for ranged breakpoints, and GCB offers:
break-range start end
in that arch. So I think you could just break on the entire memory address, or the entire text section (untested).
The command fails on x86.
Doc: https://sourceware.org/gdb/onlinedocs/gdb.html#index-break_002drange-1548
Related
I'm working on an implement of gdb server. The server talks with gdb using RSP protocol and drive a CPU model. While developing the line step function (range step mode enabled) i found that my CPU model need to take some time to finish just one instruction step. The reason is the CPU model run in individual process. I have to pass the package (instruction step) through IPC. With thousands of instructions in the source line it spend too much time compared with normal running of that line.
Can I ask gdb using temporary breakpoints ( set on any possible instruction can go out of the range corresponding to the source line) to assist with step functionality? Does gdb really knows where to set the required breakpoints? If the answer is false, is there a good way to deal with this problem?
Thank you for your time!
Ted CH
You say that you are using range-stepping mode, which would imply your gdb server already supports the vCont packet, and the r action. See this page for all the details.
The r action gives a range start and end, and you are free to step until the program counter leaves the specified range.
Your server is free to implement this as you like, so, you could place a temporary breakpoint, then resume execution until the breakpoint is hit. But, you need to think about both control flow, and traps, both of which might cause a thread to leave the range without passing through the end point.
If passing each single step through to your simulator is slow, could you not just pass the vCont range information directly through to the simulator, and have the simulator stop as soon as the program counter leaves the range? Surely this would be quicker than having multiple round trips between simulator and server.
Some debuggers (like pdb) automatically break at your first line of code, then allow you to add breakpoints as needed. I'd really like to have that functionality with gdb. (I need to trace code execution through a huge codebase, and none of my guesses as to where to set a breakpoint have been correct, so the program just runs through to the end.) I've read that you can get similar functionality with gdb's starti command, but gdb takes it a little too literally: it stops on the VERY first line of the program where the linking information is. How can I move past this and actually step into my program? I've tried running the s command, but nothing looks familiar.
Here's a picture of what I see when I run starti.
Use start, not starti. start puts a temporary breakpoint on your main() function and begins executing. It should start at the beginning of your program proper.
Are there any debuggers, tools, gdb-scripts that can be used to do code-path analysis?
Say I have an executable (in C++, but the question is not language restricted) that runs fine with one input and crashes with another. I would like to see the difference between the two execution paths, without having to step (or instrument) through potentially thousands of lines of code.
Ideally, I would be able to compare between 2 different streams of (C++) statements (preferably not assembler) and pinpoint the difference(s). Maybe a certain if-branch is taken in one execution and not the other, etc.
Is there a way to achieve / automate that? Thanks in advance.
So, provided the source of the bug could be located in one (or a few) source files, the simplest way to achieve comparative code-execution paths seems to be GDB scripting. You create a gdb script file:
set args <arg_list>
set logging off
set logging file <log_file_1>
set logging on
set pagination off
set breakpoint pending on
b <source_file>:<line_1>
commands
frame
c
end
...
b <source_file>:<line_n>
commands
frame
c
end
with a preamble (all the set commands) and then breakpoint + command for each line in the source file (which can be easily generated by a script; don't worry about blank or commented lines, they will be skipped).
Load the executable in gdb (properly built with debug flags, of course); source the gdb script file above (call it gdb_script.txt) and run:
source gdb_script.txt
run
Then repeat the process above with a slightly changed script file (gdb_script.txt). Specifically, change the <arg_list> to modify the input; and set logging file to a different file <log_file_2>.
Source and run. Then compare <log_file_1> vs. <log_file_2> with your preferred diffing tool (say, tkdiff).
This will not do a better job than gcov (suggested above). But, it can help better restrict your output to the suspicious region of code.
I am attempting to use this answer to generate an instruction trace between two lines of code.
Unfortunately, the condition in the while loop is a simple count, and I need to keep running the loop until a particular line of code in the source code is reached.
Does there exists a way to check whether we are either on a particular line of code, or at a particular breakpoint, within a pure gdb script?
I am aware of the solution here which uses the Python API. I am also aware of pin-instat, but I want to know whether this can done with pure gdb.
What if do what you want in this way
1) Get information about pc for the line which you would like to reach
Use info line or use disas /m to get information about addresses of the particular line of code.
2) Write the similar loop as in Tracing/profiling instructions
while $pc != ADDRESS-FROM-FIRST-STEP
si
end.
This way you will keep running the loop until a particular line of code in the source code is reached
I'm running through some assembly code in GDB trying to debug my program and I'd like to see what happens if I ignore an instruction entirely, is there a way to do this? (skip past it to the next line without executing it) without having to edit the source code and comment out the function and then recompile?
is there a way to do this
Sure: jump *0x1234 will jump to instruction at address 0x1234.
skip past it to the next line without executing it
"Next line" and assembly debugging rarely go together. As this answer shows, you can skip a line as well.