[Bug remote/28916] tty sharing mode for target remote

["mark at klomp dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28916

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.