I am currently trying to analyze the behavior of a large complicated function which takes in lots of pointer inputs. Consider the following signature.
int myfunc(typeA *paramA, typeB *paramB);
which is being invoked as
myfunc(argA, argB);
Is it possible to watch with the debugger if the pointer locations of argA and argB were written to? Or is it only possible to watch whether the memory location changed (that is definitely not happening in my case)?
I want to check the difference in these pointer arguments before and after the function call. Is this watch possible?
Note that these classes/structs being passed are huge having other pointers to classes/structs. So, watching each variable one by one would be my last resort
Since you've tagged your post with CLion, I assume that's the IDE you're using. You may want to read this post:
https://blog.jetbrains.com/clion/2015/05/debug-clion/
Specifically the part on Watches:
Capturing every single variable at every single point results in far too much information. Sometimes, you want to focus on a specific variable and the way it changes throughout program execution, including monitoring changes when the variable in question is not local to the code you are inspecting. This is what the Watch area of the Debug tool window is for.
To start watching a variable, simply press the Add button (Alt+Insert (Windows/Linux)/⌘N (OS X)) and type in the name of the variable to watch. Code completion is available here too.
Per your comment:
You have options to see when the memory is written to: Can I set a breakpoint on 'memory access' in GDB?
Otherwise if you just want to know if the value is changed for debugging, just copy the value before you call the function:
typeA copyOfA = *argA;
myfunc(©OfA, argB);
if (copyOfA != *argA)
{
// It's changed
}
Not sure I'm getting your question exactly, and I don't know whether clion gives you access to the lldb script interpreter, but given this example:
struct Foo
{
int a;
int b;
int c;
};
void ChangeFoo(struct Foo *input)
{
input->a += 10;
}
int
main()
{
struct Foo my_foo = {10, 20, 30};
ChangeFoo(&my_foo);
return 0;
}
from command-line lldb you can do:
(lldb) br s -l 17
Breakpoint 1: where = tryme`main + 39 at tryme.c:17, address = 0x0000000100000f97
(lldb) br s -l 18
Breakpoint 2: where = tryme`main + 46 at tryme.c:18, address = 0x0000000100000f9e
(lldb) run
Process 16017 launched: '/tmp/tryme' (x86_64)
Process 16017 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100000f97 tryme`main at tryme.c:17
14 main()
15 {
16 struct Foo my_foo = {10, 20, 30};
-> 17 ChangeFoo(&my_foo);
^
18 return 0;
19 }
Target 0: (tryme) stopped.
(lldb) script value = lldb.frame.FindVariable("my_foo")
(lldb) script print value
(Foo) my_foo = {
a = 10
b = 20
c = 30
}
(lldb) n
Process 16017 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
frame #0: 0x0000000100000f9e tryme`main at tryme.c:18
15 {
16 struct Foo my_foo = {10, 20, 30};
17 ChangeFoo(&my_foo);
-> 18 return 0;
^
19 }
Target 0: (tryme) stopped.
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> for i in range(0,value.GetNumChildren()):
... print(i, " ", value.GetChildAtIndex(i).GetValueDidChange())
...
(0, ' ', True)
(1, ' ', False)
(2, ' ', False)
>>> print value.GetChildAtIndex(0)
(int) a = 20
Note, if my_foo above had been a pointer, we would have only fetched the pointer value which isn't what you want to compare. In that case, when you capture the value do:
(lldb) script value = lldb.frame.FindVariable("my_foo_ptr").Dereference()
where you get the value originally, and then everything after will go as above.
Related
I would like to learn if existing GDB for RISC-V supports Program Context aware breakpoints?
By program context aware breakpoints : I mean, when there is JAL or JALR instruction PC changes when there is a function call. in other cases in Function call ==> PC = PC + (Current Program Counter + 4)
in Function Return : PC = PC - (Return address (ra register value) ).
I have installed fedora(risc-V) on my ubuntu(virtual machine). Since it is virtual machine I can't print PC register value, that is why I couldn't check if it supports Program Context aware breakpoint or not?
My second question is : How can I print PC register value on my qemu risc-v virtual machine?
#include<stdio.h>
int check_prime(int a)
{
int c;
for (c=2;c<a;c++)
{
if (a%c == 0 ) return 0;
if (c == a-1 ) return 1;
}
}
void oddn(int a)
{
printf("oddn --> %d is an odd number \n",a);
if (check_prime(a)) printf("oddn --> %d is a prime number\n",a);
}
int main()
{
int a;
a=7;
if (check_prime(a)) printf("%d is a prime number \n",a);
if (a%2==1) oddn(a);
}
This is the program I am trying to breakpoint using GDB.
As you see on the picture it breaks twice(which should break once only).
It also gives error :
Error in testing breakpoint condition:
Invalid data type for function to be called
What you're looking for is documented here:
https://sourceware.org/gdb/current/onlinedocs/gdb/Convenience-Funs.html#index-_0024_005fstreq_002c-convenience-function
You should look at $_caller_is, $_caller_matches, $_any_caller_is, and $_any_caller_matches.
As an example, to check if the immediate caller is a particular function we could do this:
break functionD if ($_caller_is ("functionC"))
Then main -> functionD will not trigger the breakpoint, while main -> functionC -> functionD will trigger the breakpoint.
The convenience functions I listed all take a frame offset that can be used to specify which frame GDB will check (for $_caller_is and $_caller_matches) or to limit the range of frames checked (for $_any_caller_is and $_any_caller_matches).
I am working in a project where there are more than 100 files of source code. I am debugging it for find an error.
What I need to find is the time when a particular object assigned to a value. ie. This object is NULL at first, but some other file changes its value, which I don't know.
Are there any method to find when this variable changes its value ?
What I tried upto now is to put a breakpoint on the function where the variable is initilized. I also added a watchpoint. But it does not show any point where the value is changing.
But it does not show any point where the value is changing.
There are two possible explanations:
You've set the watchpoint incorrectly, or
The value changes while the process is in kernel mode (GDB watchpoints are not effective for detecting such change).
Example:
#include <unistd.h>
int global_a;
int global_b;
int foo()
{
global_a = 42;
read(0, &global_b, 1);
return global_a + global_b;
}
int main()
{
return foo();
}
gcc -g -Wall t.c
gdb -q ./a.out
(gdb) start
Temporary breakpoint 1 at 0x400563: file t.c, line 16.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at t.c:16
16 return foo();
(gdb) watch global_a
Hardware watchpoint 2: global_a
(gdb) watch global_b
Hardware watchpoint 3: global_b
(gdb) c
Continuing.
Hardware watchpoint 2: global_a
Old value = 0
New value = 42
This is a modification of global_a in user-space (via direct assignment), and it triggers watchpoint 2 as expected
foo () at t.c:9
9 read(0, &global_b, 1);
(gdb) c
Continuing.
# Press Enter here
This read 0xA == 10 into global_b.
[Inferior 1 (process 126196) exited with code 064]
Note that the exit code is 064 == 52 == 42+10, but the watchpoint 3 did not fire.
any method to find when this variable changes its value
If you are sure that your "normal" watchpoints are working (e.g. by running above test yourself) and suspect that the variable is being changed via a system call, you can:
Print the address of the variable and
Run your program under strace and look for system calls that could change the value at variable's address.
Using the same example:
(gdb) p &global_b
$1 = (int *) 0x601044 <global_b>
strace -e raw=all ./a.out < /dev/zero
execve(0x7ffe1853e530, 0x7ffe1853f920, 0x7ffe1853f930) = 0
brk(0) = 0x2253000
access(0x7fa66eee48c3, 0) = -1 (errno 2)
mmap(0, 0x2000, 0x3, 0x22, 0xffffffff, 0) = 0x7fa66f0e8000
...
munmap(0x7f57ece26000, 0x203a2) = 0
read(0, 0x601044, 0x1) = 0x1 ### &global_b is "covered" by the buffer being read into
exit_group(42) = ?
+++ exited with 42 +++
I have a complicated class for which I have written a clean printing method, more-or-less explicitly for the purposes of debugging. However, I can't seem to figure out the syntax to actually use it to print when I'm using gdb. Basically I want to be able to type something like "myObject->print()" and have it run my print method but instead I get the following error:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000a1
0x00007fff814c0684 in std::ostream::sentry::sentry () The program
being debugged was signaled while in a function called from GDB. GDB
remains in the frame where the signal was received. To change this
behavior use "set unwindonsignal on" Evaluation of the expression
containing the function (wfSamplePath::print_traj(std::ostream&)) will
be abandoned.
where "wfSamplePath" is my class and "print_traj" is my print method (with std::cout as the default argument). So clearly something is wrong with how I think I can do this. I'm using gdb from within xcode 3. "myObject" is definitely in scope, as I can access some of its other methods.
The expression evaluator in GDB is quite limited, particularly with C++ expressions, so try to keep it simple. Particularly, do not use default arguments. Using cout is also probably a bad idea. So are inline functions.
I've got good results with a simple member function that returns a string. For example this code works as expected:
#include <sstream>
struct S
{
int x, y, z;
std::string debug();
};
std::string S::debug()
{
std::ostringstream os;
os << x << ", " << y << ", " << z;
return os.str();
}
int main()
{
S s;
s.x = 1;
s.y = 2;
s.z = 3;
return 0;
}
Then, compile and debug with:
$ g++ -O0 -g test.cpp
$ gdb ./a.out
....
$start
....
19 s.x = 1;
(gdb) n
20 s.y = 2;
(gdb) n
21 s.z = 3;
(gdb) n
22 return 0;
(gdb) p s.debug()
$1 = "1, 2, 3"
I have an object defined in c++ with a pointer to it used in various functions and files throughout the project. I am having an issue with the data being updated, so I want to debug it to see what is happening. Ideally, I want to break every time the object is accessed. however, watch requires a specific memory address. So, for example, if I have:
class data{
public:
int a;
int b;
};
then gdb will only break when a is altered, since the pointer to data is pointed at a, but not when b is altered.
Is there a way to break whenever the entire range of memory covered by the data class is altered?
Is there a way to break whenever the entire range of memory covered by the data class is altered?
Perhaps.
GDB hardware watchpoints use special debug registers in hardware, and there is usually a limit on how such registers work. On x86, you can set up to 4 word-sized hardware watch points, so for example you gave you can set watchpoints on &data->a and &data->b, and that will "cover" entire memory of the data.
I am guessing that your actual data has many more members though, and so 4 word-sized watch points will not suffice.
If you are on platform which has Valgrind support, and if your program can execute under Valgrind, then you can use Valgrind's built-in gdbserver to set watchpoints on arbitrary regions of memory.
Update:
I looked through the page you linked to and couldn't find what I was looking for
I am not sure what you were looking for. Here is a sample session showing how it works:
#include <stdlib.h>
void foo(char *p)
{
*p = 'a';
}
typedef struct {
char buf[1024];
} data;
int main()
{
data *d = calloc(1, sizeof(data));
foo(d->buf + 999);
}
gcc -g main.c
valgrind --vgdb-error=0 ./a.out
...
==10345== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10345== /path/to/gdb ./a.out
==10345== and then give GDB the following command
==10345== target remote | vgdb --pid=10345
... Valgrind now waits for debugger to attach.
In another window:
gdb ./a.out
GNU gdb (GDB) 7.4
...
(gdb) target remote | vgdb --pid=10345
relaying data between gdb and process 10345
[Switching to Thread 10345]
0x0000000004000af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x40053d: file main.c, line 14.
(gdb) c
Breakpoint 1, main () at main.c:14
14 data *d = calloc(1, sizeof(data));
(gdb) n
15 foo(d->buf + 999);
(gdb) watch *d
Hardware watchpoint 2: *d
Note that a "hardware" watchpoint has been set on entire *d.
It's a hardware watchpoint only in the sense that Valgrind is the hardware.
(gdb) p d.buf[999]
$1 = 0 '\000'
(gdb) c
Hardware watchpoint 2: *d
Old value = {buf = '\000' <repeats 1023 times>}
New value = {buf = '\000' <repeats 999 times>, "a", '\000' <repeats 23 times>}
foo (p=0x51b6457 "a") at main.c:6
6 }
(gdb) q
Voila: the debugger stopped when 999th element was modified, proving that the watchpoint "covered" the entire structure.
Last week I was a debugging a code and a weird situation came up: gdb passes through two different return clauses. I made a simple example that illustrates the situation:
#include <iostream>
using namespace std;
int test() {
string a = "asd";
string b = "asd";
while (true) {
if (a == b) {
return 0;
}
}
return -1;
}
int main() {
int result = test();
cout << "result: " << result << endl;
}
When debugging the code I got:
(gdb) b main
Breakpoint 1 at 0x1d4c: file example.cpp, line 19.
(gdb) r
Starting program: /Users/yuppienet/temp/a.out
Reading symbols for shared libraries +++. done
Breakpoint 1, main () at example.cpp:19
19 int result = test();
(gdb) s
test () at example.cpp:7
7 string a = "asd";
(gdb) n
8 string b = "asd";
(gdb) n
11 if (a == b) {
(gdb) n
12 return 0;
(gdb) n
15 return -1;
(gdb) n
16 }
(gdb) n
main () at example.cpp:20
20 cout << "result: " << result << endl;
(gdb) n
result: 0
21 }
(gdb) n
0x00001ab2 in start ()
I noted that even if gdb shows line 15, the return value is 0 (the finish command confirms this as well).
So the question is: why does gdb show line 15: return -1, even if the function is not really returning this value?
Thanks!
Edit:
I forgot to mention that I compiled with the following line:
g++ -Wall -pedantic -g -pg example.cpp
I suspect you're seeing the function epilogue. Your two strings have destructors, which are being implicitly called on return. Check out what the disassembly says to be sure, but I suspect that both return statements are mapping to something along the lines of:
stash return_value;
goto epilogue;
and correspondingly:
epilogue:
destroy a; // on the stack, so destructor will be called
destroy b;
really_return(stashed value);
The epilogue appears to come from line 15 as a side-effect of how g++ does line numbering - a fairly simple format, really just a list of tags of the form "address X comes from line number Y" - and so it's reporting 15 as the closest match. Confusing in this case, but correct a lot of the time.
Probably because the program counter register passes through the instructions that best map to the final return, i.e. the function's exit sequence. The actual return value is probably kept in a register, so the first return just loads the proper value and jumps to the end of the function, and then that address is "back-mapped" to the source code line of the final return.
You don't say, but if you compiled with optimization that is exactly the kind of behavior you would see in gdb. You see the first line setting up the return value, and then it jumps to the real return instruction but in C++ you see the entire thing including the return value.