I want to define a new command which basically sets a breakpoint on a line, print a value of a certain variable and then continues execution. Unfortunately I am having issues. Here is the code I am using
(gdb) define print_and_continue
Type commands for definition of "print_and_continue".
End with a line saying just "end".
>break $arg0
>command $bpnum
>print $arg1
>continue
>end
>end
So I want to print the value of variable len which is defined in linked_list.h:109. And I execute the following code:
(gdb) print_and_continue linked_list.h:111 len
Breakpoint 1 at 0x388a: linked_list.h:111. (12 locations)
(gdb) r
...
Breakpoint 1, linked_list<test_struct<1>, 1>::remove_if<run_test<1, 1, 1>(std::vector<int, std::allocator<int> >&)::{lambda(test_struct<1> const&)#1}>(run_test<1, 1, 1>(std::vector<int, std::allocator<int> >&)::{lambda(test_struct<1> const&)#1}&&) (this=0x7fffffffdca0, condition=...) at linked_list.h:112
112 linked_list_node* prev = nullptr;
$1 = void
It seems like $arg1 in print function didn't get replaces by the actual argument. What am I doing wrong?
It seems like $arg1 in print function didn't get replaces by the actual argument.
I don't believe that's what is actually happening. Rather, everything following command $bpnum is attached to the newly-created breakpoint literally (without any expansion at all). You can see that happening with info break, which will show something like:
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001136 at ...
print $arg1
continue
This is generally what you would want (deferring evaluating the argument until the time breakpoint is hit). Otherwise you would print current value of len if you use print len, when what you want is to print the value of len when the breakpoint is hit.
Of course, when the breakpoint is hit, there is no $arg1 (or $arg0) anywhere around, so you get the same output you'd get trying to print any other non-existent GDB variable.
What am I doing wrong?
You are using "quick hack of a language" (which is what the "native" GDB scripting language is), instead of using a proper programming language.
I am 99.99% certain that defining print_and_continue is possible (and probably quite easy) using embedded Python.
That said, I don't believe that print_and_continue is all that useful (in my 20+ years of using GDB, I never needed anything like that).
Related
Taking the example from http://shanekirk.com/2017/08/gdb-tips-and-tricks-2-setting-breakpoints-with-regular-expressions/ - when I use rbreak, I get something like:
(gdb) rb TestFixture.h:.
Breakpoint 1 at 0x4008b6: file TestFixture.h, line 5.
void TestFixture::setUp();
Breakpoint 2 at 0x4008d4: file TestFixture.h, line 6.
void TestFixture::tearDown();
Breakpoint 3 at 0x4008f2: file TestFixture.h, line 7.
void TestFixture::testA();
Breakpoint 4 at 0x400910: file TestFixture.h, line 8.
void TestFixture::testB();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004008b6 in TestFixture::setUp() at TestFixture.h:5
2 breakpoint keep y 0x00000000004008d4 in TestFixture::tearDown() at TestFixture.h:6
3 breakpoint keep y 0x00000000004008f2 in TestFixture::testA() at TestFixture.h:7
4 breakpoint keep y 0x0000000000400910 in TestFixture::testB() at TestFixture.h:8
Now, what I want is basically a dprintf-like behavior: once one of this breakpoints is hit, I just want the function name printed out, and then continue (basically, a function call trace)
However, the way I understand gdb - in order to do that, I would issue a rbreak [regex] first, then I get a bunch of breakpoints, then for each and every one of those I'd had to type manually:
commands [number-of-breakpoint]
print "[name of function]"
continue
end
... which quickly becomes a chore, especially if you end up with a lot more breakpoints than the 4 in the above example (say hundreds).
Now, it would be rather cool, if I could use something like "regex dprintf", or rdprintf, as in:
rdprintf TestFixture.h:., "%s\n", $__breakname__
... but as far as I know, there is no such command...
Or, if after issuing a rbreak TestFixture.h:., I could target the commands for those breakpoints as:
commands 1-4
print $__breakname__
continue
end
... but again, I think this does not exist either...
So is there a way to use gdb to provide this kind of a function call trace printout - without me manually typing the names of breakpoints and their commands, similar to how rbreak allows you to set multiple breakpoints with one command?
EDIT: just found List of all function calls made in an application - record function-call-history /ilc might be interesting, but there doesn't seem to be a way to limit the scope of what functions to trace, say with a regex...
Ok, via the link above, found https://stackoverflow.com/a/39124320/277826 - turns out, you can issue command for multiple breakpoints, as found by rbreak; and to print the name of the function, just use backtrace 1:
(gdb) command 1-36
Type commands for breakpoint(s) 1-36, one per line.
End with a line saying just "end".
>silent
>bt 1
>continue
>end
(gdb) r
... or with python, printing the frame at bt 0 and its parent's frame name:
command 1-36
silent
python print("{} <- {}".format( gdb.execute("bt 0", False, True).strip(), gdb.newest_frame().older().name() ))
continue
end
... or even better, python printing bt 0 function name and args, and parent name:
command 1-36
silent
python nf = gdb.newest_frame(); nfb = nf.block()
python nfargs = [ "{}={}".format(sym, nf.read_var(sym, nfb)) for sym in nfb if sym.is_argument ]
python print("#0 {}({}) <- {}".format(nf.name(), ",".join(nfargs), nf.older().name() ))
continue
end
... which would print something like:
#0 Searcher::FlagFromCmd(this=0x7fffffffaed8,cmd=808) <- FindLiveStrip::GrabToggles
#0 Searcher::FlagFromCmd(this=0x7fffffffaed8,cmd=807) <- FindLiveStrip::ToggleChanged
... and this seems to work fine; though if there are other options, I'd love to know about them.
In gdb, when it hits a breakpoint, I need to manually investigate the variable values, one by one, with print or print/x functions.
Is there any easier way to list all selected variable's values whenever it hits a breakpoint, commonly known as a "watch window" of a GUI debugger?
Commands can be executed on breakpoints.
From docs:
break foo
commands
printf "x is %d\n",x
end
Or add commands to some existing breakpoint (breakpoint number 3 in this case):
commands 3
print x
print y
end
Or make a command that adds prints to a breakpoint:
define addwatch
commands $arg0
print x
print y
end
end
Then use:
addwatch 3
Or make a command that sets a breakpoint and adds prints to it.
Scripts can be stored in .gdbinit, so they'll load automatically. The language is either this GDB syntax or Python.
P.S. Some people do tracing with this by adding continue at the end of the command list: that way the variables are printed, but the application doesn't stop on the breakpoint.
I've set a breakpoint in gdb, and I'd like to see the exact line of source the breakpoint is on, just to confirm it's correct -- is there a quick way to do this?
The "info b" command gives me information about the breakpoints, but it doesn't display source:
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000006c3ba4 in MyClass::foo(bar*)
at /home/user1/src/MyClass.cpp:1021
I can type "list MyClass.cpp:1021" to see the lines around this breakpoint, but I'm wondering if there's a shorter way. Googling and reading the gdb manual didn't turn up anything.
I know that if I'm executing the program and have hit the breakpoint, I can just type "list", but I'm asking specifically about the case where I am not at the breakpoint (the program may not even be running).
You can use the list command to show sources. list takes a "linespec", which is gdb terminology for the kinds of arguments accepted by break. So, you can either pass it whatever argument you used to make the breakpoint in the first place (e.g., list function) or you can pass it the file and line shown by info b (e.g., list mysource.c:75).
I think the closest one can get to this is by turning the history on (set history save on) and then press CTRL-R to do a reverse search for the former list command.
More specifically, change your workflow when setting a breakpoint. After each command like b main GDB shows the source file like path/to/main.cpp, line 12. Immediately use this information in a quick list main.cpp:12. To show this location later press CTRL-R and type "main".
https://sourceware.org/gdb/onlinedocs/gdb/Command-History.html
I would like GDB to perform variable substitution when I create a conditional breakpoint. For example:
set variable $my_value = 1
b my_function if my_param == $my_value
set variable $my_value = 5
b my_function if my_param == $my_value
This actually creates 2 identical breakpoints which break in my_function() when my_param equals the current value of $my_value. Hence when running my program a breakpoint is only triggered when my_param is equal to 5. What I actually wanted was two different conditional breakpoints, for the values 1 and 5.
Is there any way to make GDB set conditional breakpoints like this using the current value of a convenience variable instead of the variable itself?
I ask this question because I'm trying to create a GDB script to track memory deallocation which will automatically set conditional breakpoints, e.g.
# set breakpoint after malloc() statement of interest
b some_file.c:2238
# define commands to execute when the above breakpoint is hit
commands
# $last is set to the allocated memory address
set variable $last = new_pointer
# set conditional breakpoint in free() to check when allocated pointer is released
b free if ptr == $last
continue
end
But of course I find that this only works for the last pointer value because all my auto generated breakpoints are identical!
I am going to investigate the use of Python scripting to see if this could solve my problem, but as I have no experience of Python I wanted to post this question first! I feel sure that it should be possible to do what I am trying to achive and any help or suggestions would be much appreciated.
For completness here is how to use the eval command with my original example:
set variable $my_value = 1
eval "b my_function if my_param == %d", $my_value
set variable $my_value = 5
eval "b my_function if my_param == %d", $my_value
This generates two breakpoints for the values 1 and 5 as desired!
Use the eval command (apparently in gdb 7.2 and later)
If I set a watchpoint for a variable local to the current scope, it will be auto deleted when going out of the scope. Is there any way to set it once and keep it auto alive whenever entering the same scope?
Is there anyway to set conditional watchpoint, like watch var1 if var1==0? In my case, the condition does't work. gdb stops whenever var1's value is changed, instead of untill var1 == 0 is true. My gdb is GNU gdb 6.8-debian.
I agree with Dave that a conditional breakpoint is the way to go.
However, to do what you asked, you can use GDB's commands command to set a list of GDB commands to execute whenever a breakpoint is hit. I find this incredibly useful.
I suggest writing your GDB commands into a file so that they are easy to edit and easy to reload with the source command. Or you can specify command files to load on the GDB command line or use .gdbinit to make them load automatically.
An example of a good use of commands:
Suppose that I have a function format that is called by a lot of other functions. I want to break on it, but only after function do_step_3 has been called.
break do_step_3
commands
break format
continue
end
You could use this for your problem with something like:
break func
commands
watch var
continue
end
You can set conditions on watchpoints in the same way that you do with breakpoints. This is in the documentation but admittedly it hardly calls attention to itself.
So watch my_var if my_var > 3 works just fine, as does the condition command.
To recreate the watchpoint if the variable it is watching goes out of scope, have gdb do this automatically using a breakpoint at the start of the function as Zan has described.
You can set a watchpoint that does not go out of scope by setting it to the memory address.
(gdb) p &var1
$1 = (int *) 0x41523c0
(gdb) watch *(int *)0x41523c0
Hardware watchpoint 1: *(int *)0x41523c0
This also works for other data types and pointers.
I'm not sure which language us are using, so the exact answer will vary, but could you change the variable to either be static, global, or dynamically allocated (and don't free it when the function returns?). This way it's raw address won't change, and gdb will be able breakpoint on it.
Instead of watching the value whe it equals a specific value; you should set a conditional break point on the line where you want to check the value of var1. This should effectively have the same effect
e.g.
(gdb) break main.c:123 if (var1 == 0)