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

Marc Khouzam
2016-08-17T14:07:32Z

> 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