Is there a way to unset inferior-tty?

Is there a way to unset inferior-tty?

[Marc Khouzam]

Hi,

Is there a way to unset inferior-tty?

I'm working on different possible solutions to allow Eclipse to handle when the user
types 'run' on the GDB console.  Currently, when that happens, the inferior fails
to restart because it tries to use the previous tty which has been closed.
I wanted to test simply removing the setting for the tty to allow the inferior to
start in this case.  But I can't figure out how to unset it.

Any ideas?
Can I set it to something that would be the equivalent to unsetting it?

(gdb) show inferior-tty 
Terminal for future runs of program being debugged is "".   <------ Want this back
(gdb) set inferior-tty /dev/pts/3
(gdb) show inferior-tty 
Terminal for future runs of program being debugged is "/dev/pts/3".

(gdb) set inferior-tty
Argument required (filename to set it to.).

(gdb) set inferior-tty ""
(gdb) show inferior-tty 
Terminal for future runs of program being debugged is """". <--- Not good enough

(gdb) set inferior-tty ''
(gdb) show inferior-tty 
Terminal for future runs of program being debugged is "''". <--- Not good enough

(gdb) unset inferior-tty
Undefined unset command: "inferior-tty".  Try "help unset".

Thanks

Marc

Re: Is there a way to unset inferior-tty?

[Pedro Alves]

On 07/01/2016 07:32 PM, Marc Khouzam wrote:
> Hi,
> 
> Is there a way to unset inferior-tty?
> 
> I'm working on different possible solutions to allow Eclipse to handle when the user
> types 'run' on the GDB console.  Currently, when that happens, the inferior fails
> to restart because it tries to use the previous tty which has been closed.
> I wanted to test simply removing the setting for the tty to allow the inferior to
> start in this case.  But I can't figure out how to unset it.
> 
> Any ideas?
> Can I set it to something that would be the equivalent to unsetting it?

Can't think of any way.

Setting it to gdb's own tty ends up actually disabling gdb's tty 
settings saving/restoring, so it's not equivalent...

> 
> (gdb) show inferior-tty 
> Terminal for future runs of program being debugged is "".   <------ Want this back
> (gdb) set inferior-tty /dev/pts/3
> (gdb) show inferior-tty 
> Terminal for future runs of program being debugged is "/dev/pts/3".
> 
> (gdb) set inferior-tty
> Argument required (filename to set it to.).

I think this should just be fixed to work.

The fix should be very similar to this:

 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68

Thanks,
Pedro Alves

Re: Is there a way to unset inferior-tty?

[Simon Marchi]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On 2016-07-01 14:51, Pedro Alves wrote:
> I think this should just be fixed to work.
> 
> The fix should be very similar to this:
> 
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
> 
> Thanks,
> Pedro Alves

Hi Marc,

Here's a patch.  If you like it I'll submit it to gdb-patches with 
ChangeLog and all.

That made me realize there is an alias for this, you can use "tty 
/dev/pts/X", which is equivalent to "set inferior-tty /dev/pts/X".  
There, I just saved you about 1 hour of typing per day :).

Simon

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-resetting-an-empty-inferior-tty.patch --]
[-- Type: text/x-diff; name=0001-Allow-resetting-an-empty-inferior-tty.patch, Size: 1786 bytes --]

From 139d8e7ccc24e0efaa84ad9424f318d55dfe9eea Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Fri, 1 Jul 2016 21:23:28 -0400
Subject: [PATCH] Allow resetting an empty inferior-tty

This patch allows the user to set the inferior-tty to "empty", in order
to come back to the default behaviour of using the same tty as gdb is
using.
---
 gdb/infcmd.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 58ba1cb..97a1e35 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -151,7 +151,11 @@ void
 set_inferior_io_terminal (const char *terminal_name)
 {
   xfree (current_inferior ()->terminal);
-  current_inferior ()->terminal = terminal_name ? xstrdup (terminal_name) : 0;
+
+  if (terminal_name != NULL && strlen (terminal_name) > 0)
+    current_inferior ()->terminal = xstrdup (terminal_name);
+  else
+    current_inferior ()->terminal = NULL;
 }
 
 const char *
@@ -3224,14 +3228,14 @@ _initialize_infcmd (void)
   const char *cmd_name;
 
   /* Add the filename of the terminal connected to inferior I/O.  */
-  add_setshow_filename_cmd ("inferior-tty", class_run,
-			    &inferior_io_terminal_scratch, _("\
+  add_setshow_optional_filename_cmd ("inferior-tty", class_run,
+				     &inferior_io_terminal_scratch, _("\
 Set terminal for future runs of program being debugged."), _("\
 Show terminal for future runs of program being debugged."), _("\
 Usage: set inferior-tty /dev/pts/1"),
-			    set_inferior_tty_command,
-			    show_inferior_tty_command,
-			    &setlist, &showlist);
+				     set_inferior_tty_command,
+				     show_inferior_tty_command,
+				     &setlist, &showlist);
   add_com_alias ("tty", "set inferior-tty", class_alias, 0);
 
   cmd_name = "args";
-- 
2.9.0

RE: Is there a way to unset inferior-tty?

[Marc Khouzam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 5088 bytes --]

> > I think this should just be fixed to work.
> > 
> > The fix should be very similar to this:
> > 
> > 
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
> > 
> > Thanks,
> > Pedro Alves
> 
> Hi Marc,
> 
> Here's a patch.  If you like it I'll submit it to gdb-patches with 
> ChangeLog and all.

Thanks! Might as well submit it.

In the end I moved to a more complete solution for eclipse.   Right
after an inferior starts, eclipse will reset the tty to a new and
valid value; that way, if the user does a 'run', the tty will already
be properly set _and_ will direct inferior output to a valid eclipse
console.

FWIW, this also led me to automatically set the tty for an inferior
that is created using the GDB console with the 'add-inferior' command
(thanks to the =thread-group-added event). I think this will make for
an improved user experience with the GDB console in eclipse.

Marc
From gdb-return-45171-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 04 02:16:10 2016
Return-Path: <gdb-return-45171-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 61614 invoked by alias); 4 Jul 2016 02:16:09 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 61602 invoked by uid 89); 4 Jul 2016 02:16:08 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 testsºYES_05,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Julio, pipes, H*Ad:D*io, HTo:D*io
X-HELO: smtp.gentoo.org
Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jul 2016 02:16:07 +0000
Received: from vapier.lan (localhost [127.0.0.1])	by smtp.gentoo.org (Postfix) with SMTP id 58B5F340D81;	Mon,  4 Jul 2016 02:16:05 +0000 (UTC)
Date: Mon, 04 Jul 2016 02:16:00 -0000
From: Mike Frysinger <vapier@gentoo.org>
To: Julio Guerra <julio@farjump.io>
Cc: gdb@sourceware.org, Corinna Vinschen <corinna@vinschen.de>,	Christophe =?utf-8?Q?Plé?= <christophe@farjump.io>
Subject: Re: [RFC] Remote File I/O should allow opening non regular files
Message-ID: <20160704021605.GP4685@vapier.lan>
Mail-Followup-To: Julio Guerra <julio@farjump.io>, gdb@sourceware.org,	Corinna Vinschen <corinna@vinschen.de>,	Christophe =?utf-8?Q?Plé?= <christophe@farjump.io>
References: <42ab0baf-9cf0-76a5-17c8-fa04940dd1bb@farjump.io>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="JVVqWhpkAs5raV7A"
Content-Disposition: inline
In-Reply-To: <42ab0baf-9cf0-76a5-17c8-fa04940dd1bb@farjump.io>
X-IsSubscribed: yes
X-SW-Source: 2016-07/txt/msg00005.txt.bz2


--JVVqWhpkAs5raV7A
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-length: 758

On 02 Jul 2016 14:02, Julio Guerra wrote:
> Today's implementation of `open()` first checks if the file is a regular
> file [1]. Is there any good reason for that limitation? I can't see any
> problem in opening special files. Most of them can be used with `read()`
> and `write()` only, without `ioctl()`, like any regular file. For
> example: TTYs, /dev/random, pipes, etc.

makes sense to me to delete that entire stat block of code.  it seems like
remote_fileio_return_errno should DTRT all the time (like trying to open a
dir and failing).  although that edge case might be worth checking.

i'd note that the current code is even racy (TOCTOU) so at the very least,
it should do the open first, and then fstat the fd to do all of the type
checks.
-mike

--JVVqWhpkAs5raV7A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-length: 819

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXecbkAAoJEEFjO5/oN/WBG0YQAJhNfFDhTXIbwE4k96wonqEU
1GGFyOHiStj/ynLWkzhYac8ICkEk+MLZ4KslfRv+fpiIXDdOH1BV1kKQqmPCgWDG
gmIqzjX3eGKsWTsrVJN3Rb4tGr7w0MbQv9ffsilrZJgtlkKxzc62PB0V812ZYlvn
uTKgC5+qcgw4ELl2Kw6oiAfqKEwxxB2fprlGM25FbUuntOzhTug6g5huC5dxnYGz
VuapPoFgKKgp34N3nkLJHMyhGXZgGfGvsWcszbMG9nhDbUH8JCsRMOXbUjuNi4gZ
BipB7Jr1IqLyC9HLSqb+bNvPt8Yx9hntQnEp9RCfSCpfHjukkOZIXBEm+rEUObkL
t2LuYR8Zo8ApLd/6qp4WiBwo7pB7CeQBPiUhzVE+Ck5mf9W6ZEAQ+mgNPVc/2s+x
FYR6LL2lrFRXhrNECHaBZorH/nfA8Ftj4jgFmMxkC6xlQazv9VSGEh3PmXb6e2BM
fZT/GfqBDvh6NZWGycFYkWJSTVB9B6OKwdjm4/q//RSjx5cVkoSxXx4IhbQMVSiF
+ZW4iFtxy3N3eqmy30zp1rltZmLKLsHq5AU1ND5IqjVDuFs+S5jfTEMkQi6whn/S
dXH1ZXbLJbRdQF5WPytY1wPU5xoEvIvRvBPI+rRCSkgNR0q0N10aNyw4Y6KNXezd
0dsqyozkF9qSQQ2aX2uu
ç03
-----END PGP SIGNATURE-----

--JVVqWhpkAs5raV7A--

Re: Is there a way to unset inferior-tty?

[Bob Rossi]

On Sat, Jul 02, 2016 at 02:04:39PM +0000, Marc Khouzam wrote:
> > > I think this should just be fixed to work.
> > > 
> > > The fix should be very similar to this:
> > > 
> > > 
> > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
> > > 
> > > Thanks,
> > > Pedro Alves
> > 
> > Hi Marc,
> > 
> > Here's a patch.  If you like it I'll submit it to gdb-patches with 
> > ChangeLog and all.
> 
> Thanks! Might as well submit it.
> 
> In the end I moved to a more complete solution for eclipse.   Right
> after an inferior starts, eclipse will reset the tty to a new and
> valid value; that way, if the user does a 'run', the tty will already
> be properly set _and_ will direct inferior output to a valid eclipse
> console.

I do the same thing in CGDB.

Thanks,
Bob Rossi

RE: Is there a way to unset inferior-tty?

[Marc Khouzam]

> On Sat, Jul 02, 2016 at 02:04:39PM +0000, Marc Khouzam wrote:
> > > > I think this should just be fixed to work.
> > > >
> > > > The fix should be very similar to this:
> > > >
> > > >
> > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
> > > >
> > > > Thanks,
> > > > Pedro Alves
> > >
> > > Hi Marc,
> > >
> > > Here's a patch.  If you like it I'll submit it to gdb-patches with
> > > ChangeLog and all.
> >
> > Thanks! Might as well submit it.
> >
> > In the end I moved to a more complete solution for eclipse.   Right
> > after an inferior starts, eclipse will reset the tty to a new and
> > valid value; that way, if the user does a 'run', the tty will already
> > be properly set _and_ will direct inferior output to a valid eclipse
> > console.
> 
> I do the same thing in CGDB.

Great, that helps confirm this is a good approach.

Do you handle the output of a second inferior?
If the user does 'add-inferior' and then runs it,
I was planning on redirecting that new output to a
new Eclipse console.  This is causing me some
trouble though because when the new inferior
starts, I don't know if it was due to a 'run' or 
an 'attach', so I'm not sure if I should be expecting
some output or not.

Have you seen this too?

Thanks

Re: Is there a way to unset inferior-tty?

[Bob Rossi]

On Tue, Jul 26, 2016 at 07:22:34PM +0000, Marc Khouzam wrote:
> > On Sat, Jul 02, 2016 at 02:04:39PM +0000, Marc Khouzam wrote:
> > > > > I think this should just be fixed to work.
> > > > >
> > > > > The fix should be very similar to this:
> > > > >
> > > > >
> > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
> > > > >
> > > > > Thanks,
> > > > > Pedro Alves
> > > >
> > > > Hi Marc,
> > > >
> > > > Here's a patch.  If you like it I'll submit it to gdb-patches with
> > > > ChangeLog and all.
> > >
> > > Thanks! Might as well submit it.
> > >
> > > In the end I moved to a more complete solution for eclipse.   Right
> > > after an inferior starts, eclipse will reset the tty to a new and
> > > valid value; that way, if the user does a 'run', the tty will already
> > > be properly set _and_ will direct inferior output to a valid eclipse
> > > console.
> > 
> > I do the same thing in CGDB.
> 
> Great, that helps confirm this is a good approach.
> 
> Do you handle the output of a second inferior?
> If the user does 'add-inferior' and then runs it,
> I was planning on redirecting that new output to a
> new Eclipse console.  This is causing me some
> trouble though because when the new inferior
> starts, I don't know if it was due to a 'run' or 
> an 'attach', so I'm not sure if I should be expecting
> some output or not.
> 
> Have you seen this too?

Here's how I solved it, it's sort of ugly.

I create a pty in CGDB and tell GDB to assign the inferior to it, using 
  tty /dev/...
The inferior then writes to one end of the pty, and CGDB has a select
loop which reads from the other end.

If GDB or the inferior closes the file handle, I'll read an EOF in the
select loop. In that case, I simply create a new pty and rerun the tty command.

With that approach in mind, i'm not sure who closed the handle or why.
I just open a new one and assign it.

I didn't know, until today, that multiple inferiors could exist!
Does GDB even support one /tty per inferior in that case?
CGDB certainly doesn't support this mode.

Good Luck!

Thanks,
Bob Rossi

Re: Is there a way to unset inferior-tty?

[Bob Rossi]

On Tue, Jul 26, 2016 at 03:32:31PM -0400, Bob Rossi wrote:
> I didn't know, until today, that multiple inferiors could exist!
> Does GDB even support one /tty per inferior in that case?

Could anyone elaborate on how gdb handles multiple inferiors with the
/tty command,
  https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html

It doesn't look like you can set a tty per inferior, but maybe I'm
wrong.

Thanks,
Bob Rossi

Re: Is there a way to unset inferior-tty?

[Pedro Alves]

On 08/11/2016 03:22 PM, Bob Rossi wrote:
> On Tue, Jul 26, 2016 at 03:32:31PM -0400, Bob Rossi wrote:
>> I didn't know, until today, that multiple inferiors could exist!
>> Does GDB even support one /tty per inferior in that case?
> 
> Could anyone elaborate on how gdb handles multiple inferiors with the
> /tty command,
>   https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html
> 
> It doesn't look like you can set a tty per inferior, but maybe I'm
> wrong.

You definitely can:

 (gdb) show inferior-tty
 Terminal for future runs of program being debugged is "".
 (gdb) tty tty1
 (gdb) show inferior-tty
 Terminal for future runs of program being debugged is "tty1".
 (gdb) add-inferior
 Added inferior 2
 (gdb) inferior 2
 [Switching to inferior 2 [<null>] (<noexec>)]
 (gdb) show inferior-tty
 Terminal for future runs of program being debugged is "tty2".
 (gdb) inferior 1
 [Switching to inferior 1 [<null>] (<noexec>)]
 (gdb) show inferior-tty
 Terminal for future runs of program being debugged is "tty1".

Thanks,
Pedro Alves

RE: Is there a way to unset inferior-tty?

[Marc Khouzam]

> On 07/02/2016 03:04 PM, Marc Khouzam wrote:
> 
> > In the end I moved to a more complete solution for eclipse.   Right
> > after an inferior starts, eclipse will reset the tty to a new and
> > valid value; that way, if the user does a 'run', the tty will already
> > be properly set _and_ will direct inferior output to a valid eclipse
> > console.
> >
> > FWIW, this also led me to automatically set the tty for an inferior
> > that is created using the GDB console with the 'add-inferior' command
> > (thanks to the =thread-group-added event). I think this will make for
> > an improved user experience with the GDB console in eclipse.
> 
> Sounds to me like this will end up causing trouble.

Thanks for bringing this up.
I've been discussing your concerns with Simon, trying to find a possible
way forward.

> E.g., if you follow a big tree of processes (e.g., debug "make check"
> with "set detach-on-fork off"), you'll end up creating a useless tty
> for each of the thousands of short lived children spawned, right?

Right.  That's not good.  
In fact, even if the process is not short-lived, the forking scenario is
problematic because the child process will automatically use whatever
TTY has been used for its parent (IIUC, GDB couldn't change that, even
if it tried). So Eclipse would end up creating a useless extra TTY (as you 
mention), but could even end-up creating a user-visible console for that 
child process, even though the child process will be printing to the parent's
console.

It would seem sufficient, from a user point-of-view, to let the child re-use 
the parent's console.  We just have to make sure Eclipse is aware of that
somehow.  This may get addressed automatically by a possible solution
to your second point below.

> It's also racy.  E.g., a script can do:
> 
>  add-inferior ..
>  inferior 2
>  run
> 
> And before you managed to handle the =thread-group-added event,
> "run" has already run, so you can no longer change the inferior's
> tty.

This could even happen if the user simply copy/pasted the above 
commands into the GDB console in eclipse.
That's pretty bad, as we'd get inconsistent behaviour where sometimes
eclipse would create a new console for a new inferior and sometimes it
would not.

> Unless you're pointing all inferiors to the same tty?
> In that case, why are you destroying the original tty in
> the first place?

No, each inferior should get it's own tty so that we can handle different inputs
properly.  If I want to debug two, say, chat-clients, but that they share the
same tty, then their inputs channels will get confused.

> I wonder whether what we need is a "set default-inferior-tty TTY" command,
> that makes inferiors created with "add-inferior" inherit that
> TTY automatically?  With that, a frontend would have (or could give the
> user the) choice of making inferiors created in the console with
> add-inferior output to a separate console.  If that setting is clear,
> then output of new inferiors created on the console goes to
> gdb's console by default or to wherever the user forced with
> "set inferior-tty", just like when running gdb outside Eclipse.
> 
> In sum:
> 
>  #1 - If "set inferior-tty" is explicitly set in the inferior, use that.
>  #2 - Otherwise, if "set default-inferior-tty" is explicitly set, use that.
>  #3 - Otherwise, use gdb's tty.

"set default-inferior-tty" would nicely protect gdb's tty from inferior I/O,
so it would be an improvement.  However, it could still leave multiple
inferiors sharing the same tty for their different input streams.

If we want to have a different tty for each inferior but don't want to force
the user to provide it, Simon had the thought that GDB could
possibly create the new tty itself, for each new inferior,
and communicate it to eclipse in the =thread-group-started event.
GDB handling the tty creation would seem to be the only way to 
get past the race condition.

It would also take care of the forking issue, as GDB would tell
Eclipse that the tty used for the forked process was the same
as the tty of the parent.

Any thoughts on such an approach?

Re: Is there a way to unset inferior-tty?

[Pedro Alves]

On 08/15/2016 08:45 PM, Marc Khouzam wrote:
>> On 07/02/2016 03:04 PM, Marc Khouzam wrote:
>>
>>> In the end I moved to a more complete solution for eclipse.   Right
>>> after an inferior starts, eclipse will reset the tty to a new and
>>> valid value; that way, if the user does a 'run', the tty will already
>>> be properly set _and_ will direct inferior output to a valid eclipse
>>> console.
>>>
>>> FWIW, this also led me to automatically set the tty for an inferior
>>> that is created using the GDB console with the 'add-inferior' command
>>> (thanks to the =thread-group-added event). I think this will make for
>>> an improved user experience with the GDB console in eclipse.
>>
>> Sounds to me like this will end up causing trouble.
> 
> Thanks for bringing this up.
> I've been discussing your concerns with Simon, trying to find a possible
> way forward.
> 
>> E.g., if you follow a big tree of processes (e.g., debug "make check"
>> with "set detach-on-fork off"), you'll end up creating a useless tty
>> for each of the thousands of short lived children spawned, right?
> 
> Right.  That's not good.  
> In fact, even if the process is not short-lived, the forking scenario is
> problematic because the child process will automatically use whatever
> TTY has been used for its parent (IIUC, GDB couldn't change that, even
> if it tried). So Eclipse would end up creating a useless extra TTY (as you 
> mention), but could even end-up creating a user-visible console for that 
> child process, even though the child process will be printing to the parent's
> console.
> 
> It would seem sufficient, from a user point-of-view, to let the child re-use 
> the parent's console. 

I think that in that case, it's what the user would expect, since that's
what happens if the program is being debugged outside the debugger.

> We just have to make sure Eclipse is aware of that
> somehow.  This may get addressed automatically by a possible solution
> to your second point below.
> 
>> It's also racy.  E.g., a script can do:
>>
>>  add-inferior ..
>>  inferior 2
>>  run
>>
>> And before you managed to handle the =thread-group-added event,
>> "run" has already run, so you can no longer change the inferior's
>> tty.
> 
> This could even happen if the user simply copy/pasted the above 
> commands into the GDB console in eclipse.
> That's pretty bad, as we'd get inconsistent behaviour where sometimes
> eclipse would create a new console for a new inferior and sometimes it
> would not.
> 
>> Unless you're pointing all inferiors to the same tty?
>> In that case, why are you destroying the original tty in
>> the first place?
> 
> No, each inferior should get it's own tty so that we can handle different inputs
> properly.  If I want to debug two, say, chat-clients, but that they share the
> same tty, then their inputs channels will get confused.
> 

IMO, in that case, when creating the session from the console, then users need
to set up the different inputs themselves, similarly to how they'd need to
if doing it outside Eclipse.  That is, if I write some scripts to create
a debug session involving multiple processes that all want to process input,
then I'd want that script to work the same either within, or without Eclipse.

>> I wonder whether what we need is a "set default-inferior-tty TTY" command,
>> that makes inferiors created with "add-inferior" inherit that
>> TTY automatically?  With that, a frontend would have (or could give the
>> user the) choice of making inferiors created in the console with
>> add-inferior output to a separate console.  If that setting is clear,
>> then output of new inferiors created on the console goes to
>> gdb's console by default or to wherever the user forced with
>> "set inferior-tty", just like when running gdb outside Eclipse.
>>
>> In sum:
>>
>>  #1 - If "set inferior-tty" is explicitly set in the inferior, use that.
>>  #2 - Otherwise, if "set default-inferior-tty" is explicitly set, use that.
>>  #3 - Otherwise, use gdb's tty.
> 
> "set default-inferior-tty" would nicely protect gdb's tty from inferior I/O,
> so it would be an improvement.  However, it could still leave multiple
> inferiors sharing the same tty for their different input streams.
> 
> If we want to have a different tty for each inferior but don't want to force
> the user to provide it, 

I can see the IDE setting up a new tty automatically for launches
created by point-and-click through the GUI.

But do we really want to always create a new tty for inferiors created
on the command line?  I think that's likely to be a case of the
debugger becoming "too smart", and getting in the way.

E.g., I think that I'd be very annoyed if every "run" of my inferior
created a new separate input/output window/view.  I'd expect to see
output for all "run"s go to the same window.

I really think that the problem is that you're destroying the
original tty too soon.  E.g., here's what it sounds like
is happening:

#1 - inferior is added (not running yet, add-inferior)
#2 - tty is created
#3 - inferior's tty is set to the above (set inferior-tty ...)
#4 - inferior is run.                   (run)
#5 - inferior exits                     (Inferior ... exited normally) 
#6 - inferior is re-run.                (run)
#7 - inferior exits                     (Inferior ... exited normally) 
#8 - inferior is removed                (remove-inferiors)

IIUC, you're destroying the tty in #5, when the process first exits,
while I think you should be destroying it only in #8 the soonest.

> Simon had the thought that GDB could
> possibly create the new tty itself, for each new inferior,
> and communicate it to eclipse in the =thread-group-started event.
> GDB handling the tty creation would seem to be the only way to 
> get past the race condition.
> 
> It would also take care of the forking issue, as GDB would tell
> Eclipse that the tty used for the forked process was the same
> as the tty of the parent.
> 
> Any thoughts on such an approach?

Dunno, I suspect that will lead to its own set of problems.

Maybe for inferiors added on the command line with add-inferior,
what should be done at least with gdb 7.12 is nothing -- simply let
inferior i/o end up in gdb's terminal, just like when run
from outside eclipse.

And then, for the future, focus on how to provide a way for the user
to setup Eclipse inferior i/o views from gdb's CLI (or through a script).
I.e., make it possible to be able to do something like:

 - create 4 inferiors in gdb
 - create two Eclipse inferior input/output views
 - tell inferiors 1 and 2 to use view 1 for input/output
 - and inferiors 3 and 4 to use view 2 for input/output.

If one was able to go to the GUI and create terminal views and Eclipse
printed the tty that is behind the view (like, e.g. run the "tty" program on
them when they're created), then users could already do that manually with
"set inferior-tty".  I think that'd cover a whole set of use cases
already actually.  The question is again the lifetime of the ttys behind
the inferior input/output views.  Eclipse would need to stop destroying
them eagerly.

Thanks,
Pedro Alves

RE: Is there a way to unset inferior-tty?

[Marc Khouzam]

> From: Pedro Alves [palves@redhat.com]
> Sent: August 17, 2016 8:14 AM
> To: Marc Khouzam; Simon Marchi
> Cc: gdb@sourceware.org
> Subject: Re: Is there a way to unset inferior-tty?
> 
> On 08/15/2016 08:45 PM, Marc Khouzam wrote:
> >> On 07/02/2016 03:04 PM, Marc Khouzam wrote:
> >>
> >>> In the end I moved to a more complete solution for eclipse.   Right
> >>> after an inferior starts, eclipse will reset the tty to a new and
> >>> valid value; that way, if the user does a 'run', the tty will already
> >>> be properly set _and_ will direct inferior output to a valid eclipse
> >>> console.
> >>>
> >>> FWIW, this also led me to automatically set the tty for an inferior
> >>> that is created using the GDB console with the 'add-inferior' command
> >>> (thanks to the =thread-group-added event). I think this will make for
> >>> an improved user experience with the GDB console in eclipse.
> >>
> >> Sounds to me like this will end up causing trouble.
> >
> > Thanks for bringing this up.
> > I've been discussing your concerns with Simon, trying to find a possible
> > way forward.
> >
> >> E.g., if you follow a big tree of processes (e.g., debug "make check"
> >> with "set detach-on-fork off"), you'll end up creating a useless tty
> >> for each of the thousands of short lived children spawned, right?
> >
> > Right.  That's not good.
> > In fact, even if the process is not short-lived, the forking scenario is
> > problematic because the child process will automatically use whatever
> > TTY has been used for its parent (IIUC, GDB couldn't change that, even
> > if it tried). So Eclipse would end up creating a useless extra TTY (as you
> > mention), but could even end-up creating a user-visible console for that
> > child process, even though the child process will be printing to the parent's
> > console.
> >
> > It would seem sufficient, from a user point-of-view, to let the child re-use
> > the parent's console.
> 
> I think that in that case, it's what the user would expect, since that's
> what happens if the program is being debugged outside the debugger.
> 
> > We just have to make sure Eclipse is aware of that
> > somehow.  This may get addressed automatically by a possible solution
> > to your second point below.
> >
> >> It's also racy.  E.g., a script can do:
> >>
> >>  add-inferior ..
> >>  inferior 2
> >>  run
> >>
> >> And before you managed to handle the =thread-group-added event,
> >> "run" has already run, so you can no longer change the inferior's
> >> tty.
> >
> > This could even happen if the user simply copy/pasted the above
> > commands into the GDB console in eclipse.
> > That's pretty bad, as we'd get inconsistent behaviour where sometimes
> > eclipse would create a new console for a new inferior and sometimes it
> > would not.
> >
> >> Unless you're pointing all inferiors to the same tty?
> >> In that case, why are you destroying the original tty in
> >> the first place?
> >
> > No, each inferior should get it's own tty so that we can handle different inputs
> > properly.  If I want to debug two, say, chat-clients, but that they share the
> > same tty, then their inputs channels will get confused.
> >
> 
> IMO, in that case, when creating the session from the console, then users need
> to set up the different inputs themselves, similarly to how they'd need to
> if doing it outside Eclipse.  That is, if I write some scripts to create
> a debug session involving multiple processes that all want to process input,
> then I'd want that script to work the same either within, or without Eclipse.

If they use a script, I agree that they need to take care of the I/O redirection
themselves.  But if they just set things up in Eclipse even by using the GDB 
console, then it may be asking a bit too much for them to dive to that level of 
detail. 

> >> I wonder whether what we need is a "set default-inferior-tty TTY" command,
> >> that makes inferiors created with "add-inferior" inherit that
> >> TTY automatically?  With that, a frontend would have (or could give the
> >> user the) choice of making inferiors created in the console with
> >> add-inferior output to a separate console.  If that setting is clear,
> >> then output of new inferiors created on the console goes to
> >> gdb's console by default or to wherever the user forced with
> >> "set inferior-tty", just like when running gdb outside Eclipse.
> >>
> >> In sum:
> >>
> >>  #1 - If "set inferior-tty" is explicitly set in the inferior, use that.
> >>  #2 - Otherwise, if "set default-inferior-tty" is explicitly set, use that.
> >>  #3 - Otherwise, use gdb's tty.
> >
> > "set default-inferior-tty" would nicely protect gdb's tty from inferior I/O,
> > so it would be an improvement.  However, it could still leave multiple
> > inferiors sharing the same tty for their different input streams.
> >
> > If we want to have a different tty for each inferior but don't want to force
> > the user to provide it,
> 
> I can see the IDE setting up a new tty automatically for launches
> created by point-and-click through the GUI.
> 
> But do we really want to always create a new tty for inferiors created
> on the command line?  I think that's likely to be a case of the
> debugger becoming "too smart", and getting in the way.
> 
> E.g., I think that I'd be very annoyed if every "run" of my inferior
> created a new separate input/output window/view.  I'd expect to see
> output for all "run"s go to the same window.

That is a good question.  It may be too early to gauge what the users
of the full GDB console feature will really want.

> I really think that the problem is that you're destroying the
> original tty too soon.  E.g., here's what it sounds like
> is happening:
> 
> #1 - inferior is added (not running yet, add-inferior)
> #2 - tty is created
> #3 - inferior's tty is set to the above (set inferior-tty ...)
> #4 - inferior is run.                   (run)
> #5 - inferior exits                     (Inferior ... exited normally)
> #6 - inferior is re-run.                (run)
> #7 - inferior exits                     (Inferior ... exited normally)
> #8 - inferior is removed                (remove-inferiors)
> 
> IIUC, you're destroying the tty in #5, when the process first exits,
> while I think you should be destroying it only in #8 the soonest.

By default, Eclipse's console handling is directly mapped to the life
of the process.  So when the process exits, the tty is closed.
But I could override this behaviour.

The second problem is that we currently don't 'remove-inferior'.
Originally, using that command caused much instability (e.g., crashes).
This was many moons ago, with GDB 7.2, so the situation may be
much better now, we'll have to try it out.

> > Simon had the thought that GDB could
> > possibly create the new tty itself, for each new inferior,
> > and communicate it to eclipse in the =thread-group-started event.
> > GDB handling the tty creation would seem to be the only way to
> > get past the race condition.
> >
> > It would also take care of the forking issue, as GDB would tell
> > Eclipse that the tty used for the forked process was the same
> > as the tty of the parent.
> >
> > Any thoughts on such an approach?
> 
> Dunno, I suspect that will lead to its own set of problems.
> 
> Maybe for inferiors added on the command line with add-inferior,
> what should be done at least with gdb 7.12 is nothing -- simply let
> inferior i/o end up in gdb's terminal, just like when run
> from outside eclipse.

Yes, this discussion shows that we/I don't have sufficient knowledge
about the needed solution for the 7.12 release time-frame.
We can get the support for restarting a process (using 'run') from the 
GDB console to work, and leave the 'add-inferior' scenario for
the next release.

> And then, for the future, focus on how to provide a way for the user
> to setup Eclipse inferior i/o views from gdb's CLI (or through a script).
> I.e., make it possible to be able to do something like:
> 
>  - create 4 inferiors in gdb
>  - create two Eclipse inferior input/output views
>  - tell inferiors 1 and 2 to use view 1 for input/output
>  - and inferiors 3 and 4 to use view 2 for input/output.
> 
> If one was able to go to the GUI and create terminal views and Eclipse
> printed the tty that is behind the view (like, e.g. run the "tty" program on
> them when they're created), then users could already do that manually with
> "set inferior-tty".  I think that'd cover a whole set of use cases
> already actually.  The question is again the lifetime of the ttys behind
> the inferior input/output views.  Eclipse would need to stop destroying
> them eagerly.

Personally, I find that the value of having the IO in an Eclipse console is
in the fact that it would be done automatically for the user.
Understanding Linux tty's and using terminals is well established, but
providing some eclipse-specific way to start a console to get a tty, is probably
going too far.  At that point, the user could simply redirect to a tty in a terminal
outside of eclipse, but keep using using eclipse to control the debug session.
But I'll try to get feedback on that particular issue so we can make an informed 
decision.

Thanks for bringing up these issues!

Marc

Re: Is there a way to unset inferior-tty?

[Pedro Alves]

On 07/02/2016 02:29 AM, Simon Marchi wrote:
> On 2016-07-01 14:51, Pedro Alves wrote:
>> I think this should just be fixed to work.
>>
>> The fix should be very similar to this:
>>
>>
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=811a659a779fdf93293fe1105d99e9db171a8b68
>>
>>
>> Thanks,
>> Pedro Alves
> 
> Hi Marc,
> 
> Here's a patch.  If you like it I'll submit it to gdb-patches with
> ChangeLog and all.

I like it.

It's more idiomatic to write *str != '\0' than check strlen > 0 though.

Thanks,
Pedro Alves