Is there a way to unset inferior-tty?

Pedro Alves
Wed Aug 17 12:14:00 GMT 2016

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.

Pedro Alves

More information about the Gdb mailing list