Closed ArijanJ closed 11 months ago
Hi,
I'll check this out this weekend.
Hi,
Can you include the exact command and arguments when you run the 'record' command, and when you run the 'replay' command.
Thanks.
Actually, nevermind with those extra details.
I'm able to reproduce the problem. I'll work on it this weekend. It used to work but I've broken something.
Hi,
I stupid bug on my part. It should be fixed if you pull/clone the latest from "main".
Note, you may need to give Seer the program to load the symbols. Use the --sym flag.
$ seergdb --rr localhost:5533 --sym myprogram
Let me know what happens. Offer any suggestions. Thanks for trying Seer.
Hello,
I'm still having some problems - it now connects to the rr server fine, but trying to set a breakpoint either through the GUI or the gdb/mi command prompt gives errors.
b main
Breakpoint 1 at 0x114f: file test.c, line 7.
l
1 #include <stdio.h>
2
3 void print_loop(void) {
4 printf("Hello!\
");
5 }
6
7 int main() {
8 for(int i = 0; i < 5; i++) {
9 print_loop();
10 }
i b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000000114f in main at test.c:7
c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x114f
Command aborted.
The address look weird, but I'm not too sure how virtual memory mapping works so it might be correct. Here's the first part of the 'GDB output' window, if there's anything weird:
I run seer as ./seergdb --rr localhost:13579 --sym ~/seer/src/build/test-program
, and rr as rr replay -s 13579 -k
(after rr record -n test-program
)
Can you recreate this?
Can you include tge source for your test program and how it is compiled and linked. Thanks.
Sent from AT&T Yahoo Mail on Android
On Sun, Aug 20, 2023 at 8:24 PM, @.***> wrote:
Hello,
I'm still having some problems - it now connects to the rr server fine, but trying to set a breakpoint either through the GUI or the gdb/mi command prompt gives errors.
b main
Breakpoint 1 at 0x114f: file test.c, line 7.
l
1 #include
3 void print_loop(void) {
4 printf("Hello!\
");
5 }
6
7 int main() {
8 for(int i = 0; i < 5; i++) {
9 print_loop();
10 }
i b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000000114f in main at test.c:7
c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x114f
Command aborted.
The address look weird, but I'm not too sure how virtual memory mapping works so it might be correct. Here's the first part of the 'GDB output' window, if there's anything weird: log Reading /home/arijan/.local/share/rr/test-program-0/mmap_clone_5_test-program from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. warning: "target:/home/arijan/.local/share/rr/test-program-0/mmap_clone_5_test-program": could not open as an executable file: No such file or directory. Reading /home/arijan/.local/share/rr/test-program-0/mmap_clone_5_test-program from remote target... warning: `target:/home/arijan/.local/share/rr/test-program-0/mmap_clone_5_test-program': can't open to read symbols: No such file or directory. warning: Could not load vsyscall page because no executable was specified 0x00007f69a7211530 in ?? () Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading /usr/lib/debug/.build-id/5b/da152cf75d0de2f24431a9ab38ef1a99cbedf9.debug from remote target... Reading /lib64/ld-linux-x86-64.so.2.debug from remote target... Reading /lib64/.debug/ld-linux-x86-64.so.2.debug from remote target... Reading /usr/lib/debug//lib64/ld-linux-x86-64.so.2.debug from remote target... Reading /usr/lib/debug/lib64//ld-linux-x86-64.so.2.debug from remote target... Reading target:/usr/lib/debug/lib64//ld-linux-x86-64.so.2.debug from remote target...
This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.archlinux.org Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
I run seer as ./seergdb --rr localhost:13579 --sym ~/seer/src/build/test-program , and rr as rr replay -s 13579 -k (after rr record -n test-program)
Can you recreate this?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
It happens with any program on rr mode, but the one I used to test is:
#include <stdio.h>
void print_loop(void) {
printf("Hello!\n");
}
int main() {
for(int i = 0; i < 5; i++) {
print_loop();
}
return 0;
}
Tested simply with gcc -ggdb test.c
and clang -g test.c
Thanks. I'll try it tomorrow.
Sent from AT&T Yahoo Mail on Android
On Sun, Aug 20, 2023 at 9:00 PM, @.***> wrote:
It happens with any program on rr mode, but the one I used to test is:
void print_loop(void) { printf("Hello!\n"); }
int main() { for(int i = 0; i < 5; i++) { print_loop(); } return 0; } Tested simply with gcc -ggdb test.c and clang -g test.c
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
I tried your setup on my machine. It works fine.
Perhaps there is a mixing of "gdb" programs??? Seer grabs gdb from "/usr/bin/gdb". Perhaps "rr replay" is using a different one?
What happens when you type:
$ which gdb
Hi,
I'm going to restructure the way I launch "rr". There's a good chance this will fix the problem.
Instead of having to run "rr replay -s" in another terminal, I'll change Seer to manage/launch "rr" directly.
I'll keep you posted on the progress.
Hi again,
If you're still curious to try, you can clone/pull the latest.
I've changed up Seer so it internally uses the gdb that comes with RR. I'm thinking this will fix the problem you're encountering. Also, it's much simplier.
The short version of changes are:
# Run your program with 'rr record' to create a trace directory.
$ rr record -n --output-trace-dir=/path/to/rr/trace-directory myprog arg1 arg2
# Use Seer to start debugging.
# Seer will internally use the gdb that comes with RR.
$ seergdb --rr /path/to/rr/trace-directory
After clicking OK, Seer will immediately load the RR session and start debugging. It will break in "_start", which is just before "main()". Set your breakpoints and then continue, next, step, etc.. More info is in the Wiki.
Note, there is now a RR configuration page under "Settings -> Configure -> RR" to set the path to RR.
Here's the updated Wiki. Let me know if it works out or if you have other problems and other suggestions.
I'm going to close this PR. It can be reopened if needed.
Whenever I try connecting to an rr server, the gui hangs and these debug messages keep looping:
It never checks for a timeout, and the rr server is working fine, I can connect to it through the command it gives me (from the terminal):
gdb '-l' '10000' '-ex' 'set sysroot /' '-ex' 'target extended-remote 127.0.0.1:5533' /home/arijan/.local/share/rr/yes-0/mmap_clone_5_yes
I've tried
seergdb --rr localhost:5533
andseergdb --rr 127.0.0.1:5533
but neither work. Seer can connect to other gdb servers, just not rr. What could be the cause of this?