From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AE0F2385803F; Mon, 21 Feb 2022 14:37:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE0F2385803F From: "mark at klomp dot org" To: gdb-prs@sourceware.org Subject: [Bug remote/28916] New: tty sharing mode for target remote Date: Mon, 21 Feb 2022 14:37:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2022 14:37:22 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28916 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=3D434057#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 pac= kets (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 g= ets its stdout redirected to stderr and stdin redirected to /dev/null so that t= he 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=