|
From: Mark W. <ma...@kl...> - 2023-04-16 00:28:21
|
Hi Philippe, Thanks for testing things out. On Sat, Apr 15, 2023 at 07:58:16PM +0200, Philippe Waroquiers wrote: > I did some tests: > > philippe@md:gdbserver_tests$ gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi > Remote debugging using | vgdb --multi > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > valgrind: sleepers: command not found > syscall failed: No such file or directory > error opening /tmp/vgdb-pipe-shared-mem-vgdb-52790-by-philippe-on-md shared memory file > Remote communication error. Target disconnected.: Connection reset by peer. > (gdb) > > > > The problem is solved by giving an absolute path for the remote exec-file: > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers It doesn't need to be an absolute path, it can also be a relative path like: set remote exec-file ./sleepers Note that this is similar to how valgrind normally resolves executables. $ valgrind sleepers valgrind: sleepers: command not found $ valgrind ./sleepers ==210626== Memcheck, a memory error detector ==210626== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==210626== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==210626== Command: ./sleepers ==210626== loops/sleep_ms/burn/threads_spec/affinity: 15 1000 0 BSBSBSBS 0 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Brussels finished to sleep and/or burn London finished to sleep and/or burn main finished to sleep and/or burn Petaouchnok finished to sleep and/or burn [...] > So, it looks like gdb knows the absolute path of the program to launch, but does not pass > it to valgrind. It might be possible to have the full path given to vgdb ? Yes that would be nice. Tom Tromey suggested we create a python plugin to do some of the things we are currently requiring the user to set by hand. Paul made a gdb alias that does some of it. I hope we will add a new target valgrind to gdb itself that will do that and that does the stdin/stdout redirecting (that is a current issue with target extended-remote | ... it will "eat" the stdin/out of the child process). > The vgdb --help output is missing the --valgrind and the --vargs in the OPTIONS summary: > OPTIONS are [--pid=<number>] [--vgdb-prefix=<prefix>] > [--wait=<number>] [--max-invoke-ms=<number>] > [--port=<portnr> > [--cmd-time-out=<number>] [-l] [-T] [-D] [-d] > [--multi] > > The vgdb --help is missing \n after the --vargs description: > --vargs everything that follows is an argument for valgrind. -l arg tells to show the list of running Valgrind gdbserver and then exit. Oops. Fixed. > For > --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched. > Wouldn't it better (if possible) to by default launch the valgrind found at the same place as where vgdb is found ? Yes that would be nice, I'll look into it. But I think that normally if vgdb is on the PATH then so will valgrind. > Finally, once giving an absolute remote exec-file and an absolute path to the valgrind to launch, > I cannot have it working: > gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > Remote debugging using | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== Memcheck, a memory error detector > ==100738== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==100738== Using Valgrind-3.21.0.RC1 and LibVEX; rerun with -h for copyright info > ==100738== Command: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== > relaying data between gdb and process 100738 > syscall failed: Resource temporarily unavailable > error reading static buf readchar > syscall failed: Resource temporarily unavailable > readchar > no ack mode: unexpected buflen -1, buf > Unknown remote qXfer reply: 1 > (gdb) quit > > Not too sure what is going wrong/what I am doing wrong ... Nothing. There is something about sleepers that causes this. It also happens for me. I'll try to debug it. But it works when you give vgdb -d -d debug options... Cheers, Mark |