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

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

[mark at klomp dot org]

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

            Bug ID: 28916
           Summary: tty sharing mode for target remote
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: mark at klomp dot org
                CC: aburgess at redhat dot com, ahajkova at redhat dot com
  Target Milestone: ---

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.

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
> 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.

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

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

[mark at klomp dot 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.

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

[mark at klomp dot org]

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

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

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

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

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
> 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.

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