How do I make gdb print functions of interest as they are called, indented according to how deep in the stack they are?
I want to be able to say something like (made up):
(gdb) trace Foo* Bar* printf
And have gdb print all functions which begin with Foo or Bar, as they are called. Kind of like gnu cflow, except using the debugging symbols and only printing functions which actually get called, not all possible call flows.
Tools which won't help include cachegrind, callgrind and oprofile, which order the results by which functions were called most often. I need the order of calling preserved.
The wildcarding (or equivalent) is essential, as there are a lot of Foo and Bar funcs. Although I would settle for recording absolutely every function. Or, perhaps telling gdb to record all functions in a particular library.
Some GDB wizard must have a script for this common job!
In your case I would turn to the define command in gdb, which allows you to define a function, which can take up to 10 arguments.
You can pass in the names of functions to "trace" as arguments to the function you define, or record them all in the function itself. I'd do something like the following
define functiontrace
if $arg0
break $arg0
commands
where
continue
end
end
if $arg1
...
Arguments to a user-defined function in gdb are referenced as $arg0-$arg9. Alternatively, you could just record every function you wanted to trace in the function, instead of using $arg0-9.
Note: this will not indent as to depth in the stack trace, but will print the stack trace every time the function is called. I find this approach more useful than strace etc... because it will log any function you want, system, library, local, or otherwise.
There's rbreak cmd accepting regular expression for setting breakpoints. You can use:
(gdb) rbreak Foo.*
(gdb) rbreak Bar.*
(gdb) break printf
See this for details on breakpoints.
Then use commands to print every function as it's called. E.g. let α = the number of the last breakpoint (you can check it with i br if you missed), then do:
(gdb) commands 1-α
Type commands for breakpoint(s) 1-α, one per line.
End with a line saying just "end".
>silent
>bt 1
>c
>end
(gdb)
Some elaboration: silent suppresses unnecessary informational messages, bt 1 prints the last frame of backtrace (i.e. it's the current function), c is a shortcut for continue, to continue execution, and end is just the delimiter of command list.
NB: if you trace library functions, you may want to wait for lib to get loaded. E.g. set a break to main or whatever function, run app until that point, and only then set breakpoints you wanted.
Use the right tool for the job ;)
How to print the next N executed lines automatically in GDB?
Did you see litb's excellent anwser to a similar post here ?
He uses readelf to get interesting symbols, gdb commands to get the trace, and awk to glue all that.
Basically what you have to change is to modify his gdb command script to remove the 1 depth from backtrace to see the stack and filter specific functions, and reformat the output with an awk/python/(...) script to present it as a tree. (I admit I'm too lazy to do it now...)
You may call gdb in batch mode (using -x option), break where you need and ask for backtrace (bt), then you filter the result using grep or egrep.
Indents are more difficult, however bt output is ordered so you have current function at the top of the trace and main at very bottom.
So you create file with commands:
br <function name where to break>
run
bt
kill
quit
then run gdb <program> -x<command file>
Filter strings that starts with #<digit> - you get stack trace.
Related
I have some C++ code like this that I'm stepping through with GDB:
void foo(int num) { ... }
void main() {
Baz baz;
foo (baz.get());
}
When I'm in main(), I want to step into foo(), but I want to step over baz.get().
The GDB docs say that "the step command only enters a function if there is line number information for the function", so I'd be happy if I could remove the line number information for baz.get() from my executable. But ideally, I'd be able to tell GDB "never step into any function in the Baz class".
Does anyone know how to do this?
Starting with GDB 7.4, skip can be used.
Run info skip, or check out the manual for details: https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
Instead of choosing to "step", you can use the "until" command to usually behave in the way that you desire:
(gdb) until foo
I don't know of any way to permanently configure gdb to skip certain symbols (aside from eliding their debugging information).
Edit: actually, the GDB documentation states that you can't use until to jump to locations that aren't in the same frame. I don't think this is true, but in the event that it is, you can use advance for the same purpose:
(gdb) advance foo
Page 85 of the GDB manual defines what can be used as "location" arguments for commands that take them. Just putting "foo" will make it look for a function named foo, so as long as it can find it, you should be fine. Alternatively you're stuck typing things like the filename:linenum for foo, in which case you might just be better off setting a breakpoint on foo and using continue to advance to it.
(I think this might be better suited as a comment rather than an answer, but I don't have enough reputation to add a comment yet.)
So I've also been wanting to ignore STL, Boost, et al (collectively '3rd Party') files when debugging for a while. Yesterday I finally decided to look for a solution and it seems the nearest capability is the 'skip' command in GDB.
I found the 'skip' ability in GDB to be helpful, but it's still a nuisance for me because my program uses a lot of STL and other "3rd Party" template code. In this case I have to mark a bunch of files as skip. After the 2nd time doing so I realized it would be more helpful to be able to skip an entire directory--and most helpful to skip a directory and all subdirectories. That way I can skip, for example, /usr since none of my code lives there and I typically have no interest in debugging through 3rd party code. So I extended the 'skip' command in gdb to support a new type 'dir'. I can now do this in gdb:
skip dir /usr
and then I'm never stopped in any of my 3rd party headers.
Here's a webpage w/ this info + the patch if it helps anyone: info & patch to skip directories in GDB
It appears that this isn't possible in GDB. I've filed a bug.
Meanwhile, gdb has the skip function command. Just execute it when you are inside the uninteresting function and it will not bother you again.
skip file is also very useful to get rid of the STL internals.
As Justin has said, it has been added in gdb 7.4. For more details, take a look at the documentation.
I am debugging a problem with programmatically adding constraints. When my app crashes LLDB tells me to break on -[UIView _viewHierarchyUnpreparedForConstraint:] to debug the problem further. However, when I add a breakpoint with LLDB :
b s -n -[UIView _viewHierarchyUnpreparedForConstraint:]
I get the following warning from LLDB:
WARNING: Unable to resolve breakpoint to any actual locations.
I also tried adding a symbolic breakpoint using the Breakpoint navigator + option.
So it looks to me as if this symbol does not exist.
How can i see a list of all the symbols generated in order to make sure that this symbol exists or not?
thanks for your help
-Malena
The lldb command line is space-delimited, so if you want to pass arguments or option values to it that have spaces in them, you need to use quotes to protect the spaces. See if this works:
(lldb) b s -n "-[UIView _viewHierarchyUnpreparedForConstraint:]"
The careful reader would have noted that the command as you typed it had "-[UIView" as the option value for -n and then a dangling argument "_viewHierarchyUnpreparedForConstraint:]" and by rights (since break set takes no arguments) you should have gotten an error about break set taking no arguments. THAT is a bug...
To answer your other question, the lldb command:
(lldb) image dump symtab
will dump all the symbols in the program. You can scope this to a particular library by adding it to the command line, so for instance this one is probably in UIKit, so:
(lldb) image dump symtab UIKit
will show you only the symbols in UIKit. There's also a command to lookup particular symbols by name, image lookup -n though in general if the breakpoint setter can't find them, image lookup isn't going to find them either.
I've never used a debugger and the time has come to give them a try. MinGW appears to come with GDB which I've been trying to use. Supposdly running gdb from the command line and typing run myprog.exe starts the debugger but when I do this I get
Starting program: C:\MinGW\bin\myprog.exe MyProg.exe
[New Thread 1828.0xd8c]
Error opening file.
[Inferior 1 (process 1828) exited with code 02]
How to proceed or what's an easier way?
In particular I'm trying to flush out undefined behavior.
Since your program terminates, you'll need to set a breakpoint to see anything. Try break main before the run line. Then you can do commands line next (next line), step (step into/outof function calls), print expression (where expression can be a variable name or a function-call or a calculation), display expression (same as print, but prints just before each prompt). At any given point you can type backtrace to get a call stack. You can even type up and down to move up the callstack, so you can print higher local variables.
Well, the easiest way would be to use an IDE, actually. You might want to give code::blocks a try - very easy to use, configures everything for you on installation (just make sure to pick a compiler - don't worry, it'll prompt you) and there, you're all set and ready to go. As it's multi-platform, it doesn't really lock you into windows either, and gives you very powerful (and, I guess more importantly, convenient) possibilities of graphical debugging.
pass the binary with gdb
gdb <binary>
then set breakpoint to main
gdb) break main
Then run your program in gdb
gdb) run
then break point hits use 'n' or 'next' to step to different lines
gdb) n
Use 's' for stepping into function and 'p' printing var value
Example :
gdb) s <fun_name>
gdb) p x
I would suggest , as a beginner start off with Visual Studio. It has a very good and easy to use debugger. Just create a break point in the line from which you want to start debugging (click on the left bar beside the line or right click and create a break point). Once your break points are set you can just simply run the program in debug mode and the execution of the program will halt in the point where the break was created.
At this point you should be able to view all valuable information about the execution of the program. You can use F10 to continue the execution step or F11 to step inside the execution tree.
The debugger as many other advanced features like break on condition , hit count etc but you can start off with it's basic functionality.
If I compiled a program like this:
gcc -o my-prog -g myprog.c
I could then debug the executable my-prog it like this:
gdb my-prog
The -g option tells gcc to generate full debugging info. Other compilers will have their own versions of this option (e.g. the MSVC cl command has the /Zi option).
Since you're having issues running the gdb on your program, it might be worth checking if it was compiled with debugging info in the first place. The debugging info is usually generated in the same location as where you compiled your program.
Using Valgrind or any other debugger in Linux, how can one see places where a variable is modified. I am using gcc. Note that I don't want to step into the code using gdb. I just want to run the program and have the debugger report me in the end, places where the variable is modified in the code.
Hm, thinking about it it's not exact duplicate of Can I set a breakpoint on 'memory access' in GDB?, because it asks a little bit more. So:
Use gdb
Find the address you want to watch (hardware watchpoints only work for watching address, so you have to run it to the point where the variable or object are instantiated, take their address and use the watch command on that address.
Attach command to the address to give you a backtrace (or any other info you need to collect) and continue.
So you'll have something like:
p &variable
watch *$$
cmd
bt
c
end
(I am not completely sure with the $$, I normally use the $n as printed by the p command).
Use Breakpoint Command Lists to do this in gdb. You will have to know the address of variable to watch. Set watchpoint with a series of commands like this:
watch *0xfeedface
commands
silent
bt
cont
end
You can also optionally save all this output to log file. Look gdb doc for more details.
I have an application. I have the source code (in C). I can compile it anyway I want. Add whatever tool I want to it. Etc. However, I do not want to pepper the source code with a bunch of printf's. I want to be able to produce a log of some sort that shows when a particular value (some member of a global structure for example) is written to (its value changes). I'd like to be able to show source file and line number, and the old and new value.
I'd also like to be able to specify the value by name, not address. But address is OK. Bonus points if I can specify a value that is local to a function.
I'm still scratching my head trying to figure out gdb's trace commands. Any help is greatly appreciated. Thanks.
First, you'll need to make sure to compile your program with debug symbols, and probably w/o optimization to make gdb most useful. For gcc, that'd be -g -O0.
Second, the feature you're looking for isn't tracing, its watchpoints.
(gdb) help watch
Set a watchpoint for an expression.
A watchpoint stops execution of your program whenever the value of
an expression changes.
So, given some example code:
int main() {
int a;
a = 1;
a = 2;
return 0;
}
you can then run gdb on it, and:
(gdb) b main
Breakpoint 1 at 0x80483a5: file test.c, line 4.
(gdb) run
Starting program: /tmp/test
Breakpoint 1, main () at test.c:4
4 a = 1;
(gdb) watch a
Hardware watchpoint 2: a
(gdb) c
Continuing.
Hardware watchpoint 2: a
Old value = -1207552288
New value = 2
main () at test.c:8
8 return 0;
it's working slightly funny due to a being on the stack, not memory. And if optimization were on, it'd work even less: a would be optimized out.
As stated already, you need to set a watchpoint on your variable.
The you use the "commands" command
(gdb) help commands
Set commands to be executed when a breakpoint is hit.
Give breakpoint number as argument after "commands".
With no argument, the targeted breakpoint is the last one set.
The commands themselves follow starting on the next line.
Type a line containing "end" to indicate the end of them.
Give "silent" as the first line to make the breakpoint silent;
then no output is printed when it is hit, except what the commands print.
So, find the watchpoint number from the watch command, and do this (assuming your watch is the second break)
(gdp) commands 2
> print a
> cont
> end
Assuming a is the variable you want. You can leave out the print line if you're happy with the output gdb gives you anyway.
You can also use the commands in your original breakpoint to set the watchpoint and continue.
Thank you both #derobert and #peter! I finally went back to this, and this:
break main
commands
watch somevar
commands
cont
end
cont
end
run
does the trick. This works when "somevar" is global, or local to "main". If "somevar" is local to anther function, just replace "main" with that function name above.
Put these commands in a file (e.g. "gdbscript") and run gdb like:
gdb -x gdbscript a.out