From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88214 invoked by alias); 15 Aug 2016 19:49:52 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 88196 invoked by uid 89); 15 Aug 2016 19:49:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:14.03.0301.000, H*r:14.03.0301.000, Hx-spam-relays-external:14.03.0301.000, bringing X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Aug 2016 19:49:49 +0000 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id 48.98.02568.2BD12B75; Mon, 15 Aug 2016 21:53:22 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 15:45:24 -0400 From: Marc Khouzam To: Pedro Alves , Simon Marchi CC: "gdb@sourceware.org" Subject: RE: Is there a way to unset inferior-tty? Date: Mon, 15 Aug 2016 19:49:00 -0000 Message-ID: References: <302246af-a394-4a76-5223-5cac924bda9a@redhat.com> <9560791fd070c79f7ab54e5e7b63d433@simark.ca> ,<875b0391-3b94-c3d7-c829-a8c3abb00770@redhat.com> In-Reply-To: <875b0391-3b94-c3d7-c829-a8c3abb00770@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00030.txt.bz2 > On 07/02/2016 03:04 PM, Marc Khouzam wrote: >=20 > > 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 =3Dthread-group-added event). I think this will make for > > an improved user experience with the GDB console in eclipse. >=20 > 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.=20=20 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= =20 mention), but could even end-up creating a user-visible console for that=20 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-us= e=20 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: >=20 > add-inferior .. > inferior 2 > run >=20 > And before you managed to handle the =3Dthread-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=20 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 i= nputs properly. If I want to debug two, say, chat-clients, but that they share t= he 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. >=20 > In sum: >=20 > #1 - If "set inferior-tty" is explicitly set in the inferior, use that. > #2 - Otherwise, if "set default-inferior-tty" is explicitly set, use tha= t. > #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 =3Dthread-group-started event. GDB handling the tty creation would seem to be the only way to=20 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?