|
From: Josef W. <Jos...@gm...> - 2011-05-20 20:37:40
|
Hi Philippe, On Tuesday 17 May 2011, Philippe Waroquiers wrote: > Julian has recently committed a patch which implements vgdb -l > giving the list of Valgrind gdbserver. > This should allow you to start converting callgrind_control to vgdb. Will do. "-l" looks fine on a first look. But the list should go to stdout, as it is the regular output when asking for it. On my Ubuntu, I am just running the kernel supporting ptrace_scope, and checked the behavior with a callgrind run blocking in a system call. If I do e.g. "vgdb help", I am flooded with syscall failed: Operation not permitted attach main pid PTRACE_ATTACH pid 23194 -1 error attach main pid 23194 syscall failed: Operation not permitted attach main pid PTRACE_ATTACH pid 23194 -1 error attach main pid 23194 syscall failed: Operation not permitted attach main pid PTRACE_ATTACH pid 23194 -1 error attach main pid 23194 ... If the client code in callgrind gets back from the blocking syscall, I eventually get the result of "vgdb help". I am not sure it makes sense to try to run PTRACE_ATTACH multiple times if the first fails. I think once is enough, and the error message can be extended to give the hint on ptrace_scope from "vgdb -h". But yes, it is sensible to block/wait for the valgrind process to return from the blocking syscall and answer the request. I thought using "vgdb --wait=1 help" allows you to specify a timeout after vgdb stops its attach try. But that does not work. What do I miss? Josef |
|
From: Philippe W. <phi...@sk...> - 2011-05-20 20:49:56
|
> Will do. "-l" looks fine on a first look. But the list should go > to stdout, as it is the regular output when asking for it. For a standalone vgdb, writing the list on stdout is ok. I will take a look at this. Note : a vgdb used as a relay will still output this on stderr, otherwise, the list will be interpreted by gdb as a wrong protocol reply. > I am not sure it makes sense to try to run PTRACE_ATTACH multiple times > if the first fails. I think once is enough, and the error message > can be extended to give the hint on ptrace_scope from "vgdb -h". > But yes, it is sensible to block/wait for the valgrind process to return > from the blocking syscall and answer the request. Yes, effectively, it looks better to output the error msg only once. > I thought using "vgdb --wait=1 help" allows you to specify a timeout > after vgdb stops its attach try. But that does not work. What do I miss? The --wait option is used to wait for a gdbserver to "appear", not for the gdbserver to respond to a command. In other words, with --wait=20, vgdb will every second during 20 seconds try to find a FIFO. If after 20 seconds, no FIFO is found; vgdb exits. Otherwise, once it has found such a FIFO, it will send the command, and wait for the answer. This --wait is mostly useful for the automatic regression tests. Philippe |
|
From: Josef W. <Jos...@gm...> - 2011-05-20 21:21:57
|
On Friday 20 May 2011, Philippe Waroquiers wrote: > > Will do. "-l" looks fine on a first look. But the list should go > > to stdout, as it is the regular output when asking for it. > For a standalone vgdb, writing the list on stdout is ok. > I will take a look at this. > Note : a vgdb used as a relay will still output this on stderr, otherwise, the list > will be interpreted by gdb as a wrong protocol reply. Sure! > > I am not sure it makes sense to try to run PTRACE_ATTACH multiple times > > if the first fails. I think once is enough, and the error message > > can be extended to give the hint on ptrace_scope from "vgdb -h". > > But yes, it is sensible to block/wait for the valgrind process to return > > from the blocking syscall and answer the request. > Yes, effectively, it looks better to output the error msg only once. With vgdb used in callgrind_control, the user would see the same error msg. I assume that is fine. > > I thought using "vgdb --wait=1 help" allows you to specify a timeout > > after vgdb stops its attach try. But that does not work. What do I miss? > > The --wait option is used to wait for a gdbserver to "appear", not for > the gdbserver to respond to a command. I see. Currently, callgrind_control also blocks indefinitely if the callgrind process does not react. But for a GUI using callgrind_control in the background, it would be good to be able to specify a timeout (the current trunk/master branch of qtcreator can run callgrind and uses callgrind_control for commands). Best, Josef |