Watching local variables in gdb without stopping execution
up vote
0
down vote
favorite
I am attempting to have GDB print the value of a variable when it changes.
Given an example program, I would like to get the value of x
in func
when it changes, but for the program to continue without prompt:
#include <stdio.h>
#include <stdlib.h>
int func(int x, int y);
int main(void)
int x = 5;
int y;
y = func(x, 4);
printf("%dn", x);
printf("%dn", y);
return EXIT_SUCCESS;
int func(int x, int y)
y *= 2;
x += y;
return x;
What I have attempted:
break func
commands
silent
watch x
commands
continue
end
continue
end
While this will successfully acquire the value of x
when it changes, the problem is that when leaving the scope of x
, gdb will stop to inform me that it is leaving the scope of x
and that it is deleting the watchpoint. Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
I came across this question: gdb: do not break when watchpoint on local variable goes out of scope
However it never did receive a solution.
c gdb watchpoint
add a comment |
up vote
0
down vote
favorite
I am attempting to have GDB print the value of a variable when it changes.
Given an example program, I would like to get the value of x
in func
when it changes, but for the program to continue without prompt:
#include <stdio.h>
#include <stdlib.h>
int func(int x, int y);
int main(void)
int x = 5;
int y;
y = func(x, 4);
printf("%dn", x);
printf("%dn", y);
return EXIT_SUCCESS;
int func(int x, int y)
y *= 2;
x += y;
return x;
What I have attempted:
break func
commands
silent
watch x
commands
continue
end
continue
end
While this will successfully acquire the value of x
when it changes, the problem is that when leaving the scope of x
, gdb will stop to inform me that it is leaving the scope of x
and that it is deleting the watchpoint. Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
I came across this question: gdb: do not break when watchpoint on local variable goes out of scope
However it never did receive a solution.
c gdb watchpoint
You don't want to useprintf
?
– Fiddling Bits
Nov 6 at 14:25
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am attempting to have GDB print the value of a variable when it changes.
Given an example program, I would like to get the value of x
in func
when it changes, but for the program to continue without prompt:
#include <stdio.h>
#include <stdlib.h>
int func(int x, int y);
int main(void)
int x = 5;
int y;
y = func(x, 4);
printf("%dn", x);
printf("%dn", y);
return EXIT_SUCCESS;
int func(int x, int y)
y *= 2;
x += y;
return x;
What I have attempted:
break func
commands
silent
watch x
commands
continue
end
continue
end
While this will successfully acquire the value of x
when it changes, the problem is that when leaving the scope of x
, gdb will stop to inform me that it is leaving the scope of x
and that it is deleting the watchpoint. Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
I came across this question: gdb: do not break when watchpoint on local variable goes out of scope
However it never did receive a solution.
c gdb watchpoint
I am attempting to have GDB print the value of a variable when it changes.
Given an example program, I would like to get the value of x
in func
when it changes, but for the program to continue without prompt:
#include <stdio.h>
#include <stdlib.h>
int func(int x, int y);
int main(void)
int x = 5;
int y;
y = func(x, 4);
printf("%dn", x);
printf("%dn", y);
return EXIT_SUCCESS;
int func(int x, int y)
y *= 2;
x += y;
return x;
What I have attempted:
break func
commands
silent
watch x
commands
continue
end
continue
end
While this will successfully acquire the value of x
when it changes, the problem is that when leaving the scope of x
, gdb will stop to inform me that it is leaving the scope of x
and that it is deleting the watchpoint. Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
I came across this question: gdb: do not break when watchpoint on local variable goes out of scope
However it never did receive a solution.
c gdb watchpoint
c gdb watchpoint
asked Nov 6 at 14:23
Christian Gibbons
1,859614
1,859614
You don't want to useprintf
?
– Fiddling Bits
Nov 6 at 14:25
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26
add a comment |
You don't want to useprintf
?
– Fiddling Bits
Nov 6 at 14:25
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26
You don't want to use
printf
?– Fiddling Bits
Nov 6 at 14:25
You don't want to use
printf
?– Fiddling Bits
Nov 6 at 14:25
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
You can give gdb's watch
command the -l
option, and the watchpoint won't be deleted (nor execution stopped) when the variable goes out of scope.
But with this type of watchpoint, gdb will pick up changes that other functions make to that same address on the stack. So you can add the qualification if $_caller_is("func", 0)
to the watchpoint so that gdb will only notify you if the variable changes within func
.
(gdb) list func
18 int func(int x, int y)
19 y *= 2;
20 x += y;
21 return x;
22
(gdb) b func
Breakpoint 1 at 0x400580: file s2.c, line 19.
(gdb) set $funcbp = $bpnum
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
># We can only set a watchpoint on a local var
># when it's visible, so we'll set it on entry to func.
># But we don't want to set it more than once
># if func is called more than once,
># so we disable the func breakpoint on first use.
>disable $funcbp
>watch -l x if $_caller_is("func", 0)
>commands
>continue
>end
>continue
>end
(gdb) r
Starting program: /home/mp/s2
Breakpoint 1, func (x=5, y=4) at s2.c:19
19 y *= 2;
Hardware watchpoint 2: -location x
Hardware watchpoint 2: -location x
Old value = 5
New value = 13
func (x=13, y=8) at s2.c:21
21 return x;
5
13
[Inferior 1 (process 29495) exited normally]
add a comment |
up vote
0
down vote
Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
No.
However you can add a breakpoint on return, and attach commands to that breakpoint to remove the watchpoint and continue. Then there will not be any active watchpoint for GDB to auto-remove, and so it will not stop when the function returns.
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something likegdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.
– Christian Gibbons
Nov 7 at 7:37
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
You can give gdb's watch
command the -l
option, and the watchpoint won't be deleted (nor execution stopped) when the variable goes out of scope.
But with this type of watchpoint, gdb will pick up changes that other functions make to that same address on the stack. So you can add the qualification if $_caller_is("func", 0)
to the watchpoint so that gdb will only notify you if the variable changes within func
.
(gdb) list func
18 int func(int x, int y)
19 y *= 2;
20 x += y;
21 return x;
22
(gdb) b func
Breakpoint 1 at 0x400580: file s2.c, line 19.
(gdb) set $funcbp = $bpnum
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
># We can only set a watchpoint on a local var
># when it's visible, so we'll set it on entry to func.
># But we don't want to set it more than once
># if func is called more than once,
># so we disable the func breakpoint on first use.
>disable $funcbp
>watch -l x if $_caller_is("func", 0)
>commands
>continue
>end
>continue
>end
(gdb) r
Starting program: /home/mp/s2
Breakpoint 1, func (x=5, y=4) at s2.c:19
19 y *= 2;
Hardware watchpoint 2: -location x
Hardware watchpoint 2: -location x
Old value = 5
New value = 13
func (x=13, y=8) at s2.c:21
21 return x;
5
13
[Inferior 1 (process 29495) exited normally]
add a comment |
up vote
1
down vote
accepted
You can give gdb's watch
command the -l
option, and the watchpoint won't be deleted (nor execution stopped) when the variable goes out of scope.
But with this type of watchpoint, gdb will pick up changes that other functions make to that same address on the stack. So you can add the qualification if $_caller_is("func", 0)
to the watchpoint so that gdb will only notify you if the variable changes within func
.
(gdb) list func
18 int func(int x, int y)
19 y *= 2;
20 x += y;
21 return x;
22
(gdb) b func
Breakpoint 1 at 0x400580: file s2.c, line 19.
(gdb) set $funcbp = $bpnum
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
># We can only set a watchpoint on a local var
># when it's visible, so we'll set it on entry to func.
># But we don't want to set it more than once
># if func is called more than once,
># so we disable the func breakpoint on first use.
>disable $funcbp
>watch -l x if $_caller_is("func", 0)
>commands
>continue
>end
>continue
>end
(gdb) r
Starting program: /home/mp/s2
Breakpoint 1, func (x=5, y=4) at s2.c:19
19 y *= 2;
Hardware watchpoint 2: -location x
Hardware watchpoint 2: -location x
Old value = 5
New value = 13
func (x=13, y=8) at s2.c:21
21 return x;
5
13
[Inferior 1 (process 29495) exited normally]
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
You can give gdb's watch
command the -l
option, and the watchpoint won't be deleted (nor execution stopped) when the variable goes out of scope.
But with this type of watchpoint, gdb will pick up changes that other functions make to that same address on the stack. So you can add the qualification if $_caller_is("func", 0)
to the watchpoint so that gdb will only notify you if the variable changes within func
.
(gdb) list func
18 int func(int x, int y)
19 y *= 2;
20 x += y;
21 return x;
22
(gdb) b func
Breakpoint 1 at 0x400580: file s2.c, line 19.
(gdb) set $funcbp = $bpnum
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
># We can only set a watchpoint on a local var
># when it's visible, so we'll set it on entry to func.
># But we don't want to set it more than once
># if func is called more than once,
># so we disable the func breakpoint on first use.
>disable $funcbp
>watch -l x if $_caller_is("func", 0)
>commands
>continue
>end
>continue
>end
(gdb) r
Starting program: /home/mp/s2
Breakpoint 1, func (x=5, y=4) at s2.c:19
19 y *= 2;
Hardware watchpoint 2: -location x
Hardware watchpoint 2: -location x
Old value = 5
New value = 13
func (x=13, y=8) at s2.c:21
21 return x;
5
13
[Inferior 1 (process 29495) exited normally]
You can give gdb's watch
command the -l
option, and the watchpoint won't be deleted (nor execution stopped) when the variable goes out of scope.
But with this type of watchpoint, gdb will pick up changes that other functions make to that same address on the stack. So you can add the qualification if $_caller_is("func", 0)
to the watchpoint so that gdb will only notify you if the variable changes within func
.
(gdb) list func
18 int func(int x, int y)
19 y *= 2;
20 x += y;
21 return x;
22
(gdb) b func
Breakpoint 1 at 0x400580: file s2.c, line 19.
(gdb) set $funcbp = $bpnum
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
># We can only set a watchpoint on a local var
># when it's visible, so we'll set it on entry to func.
># But we don't want to set it more than once
># if func is called more than once,
># so we disable the func breakpoint on first use.
>disable $funcbp
>watch -l x if $_caller_is("func", 0)
>commands
>continue
>end
>continue
>end
(gdb) r
Starting program: /home/mp/s2
Breakpoint 1, func (x=5, y=4) at s2.c:19
19 y *= 2;
Hardware watchpoint 2: -location x
Hardware watchpoint 2: -location x
Old value = 5
New value = 13
func (x=13, y=8) at s2.c:21
21 return x;
5
13
[Inferior 1 (process 29495) exited normally]
edited Nov 13 at 23:33
answered Nov 7 at 16:38
Mark Plotnick
5,37011020
5,37011020
add a comment |
add a comment |
up vote
0
down vote
Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
No.
However you can add a breakpoint on return, and attach commands to that breakpoint to remove the watchpoint and continue. Then there will not be any active watchpoint for GDB to auto-remove, and so it will not stop when the function returns.
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something likegdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.
– Christian Gibbons
Nov 7 at 7:37
add a comment |
up vote
0
down vote
Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
No.
However you can add a breakpoint on return, and attach commands to that breakpoint to remove the watchpoint and continue. Then there will not be any active watchpoint for GDB to auto-remove, and so it will not stop when the function returns.
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something likegdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.
– Christian Gibbons
Nov 7 at 7:37
add a comment |
up vote
0
down vote
up vote
0
down vote
Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
No.
However you can add a breakpoint on return, and attach commands to that breakpoint to remove the watchpoint and continue. Then there will not be any active watchpoint for GDB to auto-remove, and so it will not stop when the function returns.
Is there any way to set GDB to go ahead and continue execution without a user prompt upon auto-removing a watchpoint?
No.
However you can add a breakpoint on return, and attach commands to that breakpoint to remove the watchpoint and continue. Then there will not be any active watchpoint for GDB to auto-remove, and so it will not stop when the function returns.
answered Nov 7 at 6:58
Employed Russian
121k19161230
121k19161230
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something likegdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.
– Christian Gibbons
Nov 7 at 7:37
add a comment |
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something likegdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.
– Christian Gibbons
Nov 7 at 7:37
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something like
gdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.– Christian Gibbons
Nov 7 at 7:37
The problem with this approach is that gdb doesn't have any built-in break-at-return, either. I saw your solution to enacting a break-at-return, but it involved some manual work to find the point of return, which would not be ideal. I would like to be able to do something like
gdb -x <commands_file> attach <pid>
and have it work on binaries compiled with different versions of the code.– Christian Gibbons
Nov 7 at 7:37
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53173854%2fwatching-local-variables-in-gdb-without-stopping-execution%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You don't want to use
printf
?– Fiddling Bits
Nov 6 at 14:25
@FiddlingBits In a perfect world, yes, that would be ideal. However the pesky real world comes in sometimes and delivers less than ideal constraints. I understand why one would look at this as a likely XY problem, but I would prefer in this case if we just took it on face value that there is a need to use GDB to watch a variable and preferably not stop the program to prompt for user input.
– Christian Gibbons
Nov 6 at 17:26