This would help with better integration if valgrind and gdb: https://bugs.kde.org/show_bug.cgi?id=434057#c4 valgrind comes with a remote gdbserver which gdb can connect to with target remote | vgdb Currently this requires two separate terminals, one to run valgrind and one to run gdb. We would like to be able to run completely from gdb. This would be possible if we extend vgdb (the remote gdb bridge) with extended-remote packets (and possibly multiprocess ones). But currently the two target modes that gdb provides don't allow sharing of stdio/tty with gdb like a native binary would. Socket mode: (gdb) target remote HOST:PORT Currently vgdb/valgrind doesn't support this mode, but we hope to add this. But in this mode the valgrind process does its stdio in its own terminal. stdio mode: (gdb) target remote | PROGRAM ARGS This is the current way vgdb operates. This is somewhat equivalent to using gdbserver -. In this mode (when using --multi) a process that is launched gets its stdout redirected to stderr and stdin redirected to /dev/null so that the inferior i/o doesn't corrupt the connection. What we're proposing would a third mechanism for starting a remote. This new approach is kind of like the second approach above, but has some extra promises made to gdb, specifically, we will know that the "remote" is actually running within gdb, and shares our tty. As a result we will fill in the tty hooks for the remote target so that control is handled correctly.
> a process that is launched gets its stdout redirected to stderr and stdin > redirected to /dev/null so that the inferior i/o doesn't corrupt the connection. What if it captured the connection and then sent the output back over the connection? This can be done in all-stop mode (not in non-stop) with 'O' packets. I'm not sure what to do about input though. Maybe that would just not work. Another idea is to look at Pedro's "tty" series and see if that can help solve this. (Just a random thought, no idea if it helps) One advantage of making this work in gdbserver is that the valgrind stuff could be used remotely: (gdb) target remote | ssh machine valgrind blah If none of this works, it would be pretty easy to write a bit of "target valgrind" code that acts like "extended-remote" but passes a new file descriptor and tells valgrind about it.
(In reply to Tom Tromey from comment #1) > > a process that is launched gets its stdout redirected to stderr and stdin > > redirected to /dev/null so that the inferior i/o doesn't corrupt the connection. > > What if it captured the connection and then sent the output back > over the connection? This can be done in all-stop mode (not in non-stop) > with 'O' packets. > > I'm not sure what to do about input though. > Maybe that would just not work. Where are 'O' packets described? I cannot find it on https://www.sourceware.org/gdb/onlinedocs/gdb/Packets.html I think it should work for both input and output, otherwise it simply isn't equal to native debugging. > Another idea is to look at Pedro's "tty" series and see if that > can help solve this. (Just a random thought, no idea if it helps) What and where is Pedro's "tty" series? > One advantage of making this work in gdbserver is that the valgrind > stuff could be used remotely: > > (gdb) target remote | ssh machine valgrind blah > > If none of this works, it would be pretty easy to write a bit > of "target valgrind" code that acts like "extended-remote" but > passes a new file descriptor and tells valgrind about it. So when you say gdbserver, do you mean gdb-gdbserver or the partial gdbserver as implemented in valgrind? I do like to make this work for gdb-gdbserver too so that remote and native debugging because more equal (when possible, like when running gdbserver on the local host or inside a container on the same host). Also wrt ssh machine valgrind as remote target, do you mean ssh machine vgdb? Asking because there seems a bit of confusion about the builtin valgrind gdbserver. Which cannot simply be invocated as is, but needs to communicate through vgdb (valgrind runs as the the actual inferior, including not having its own threads, so vgdb has some trickery to invoke the valgrind builtin gdbserver if all the inferior threads are "stuck". See also https://bugs.kde.org/show_bug.cgi?id=434057 and https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_gdbserver/README_DEVELOPERS;hb=HEAD
(In reply to Tom Tromey from comment #1) > If none of this works, it would be pretty easy to write a bit > of "target valgrind" code that acts like "extended-remote" but > passes a new file descriptor and tells valgrind about it. Yes, I do think we will end up with a target valgrind to hide some of the complexity (like having to invoke vgdb with some arguments to connect to or launch valgrind and the actual inferior).
> Where are 'O' packets described https://www.sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets > > > Another idea is to look at Pedro's "tty" series and see if that > > can help solve this. (Just a random thought, no idea if it helps) > > What and where is Pedro's "tty" series? The tty-always-separate-session branch on his github. > So when you say gdbserver, do you mean gdb-gdbserver or the partial > gdbserver as implemented in valgrind? valgrind, but really it would be good for both, and if it was in both then it could be tested in-tree a bit. > Also wrt ssh machine valgrind as remote target, do you mean ssh machine vgdb? Yeah. That is, the valgrind work is making valgrind easier to use in gdb. So, ideally, it would also be just as easy to use over ssh.