Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Bob Rossi <bob@brasko.net>
Cc: Alain Magloire <alain@qnx.com>,
	Nick Roberts <nickrob@snap.net.nz>,
	gdb-patches@sources.redhat.com
Subject: Re: MI testsuite improvements
Date: Mon, 21 Feb 2005 02:12:00 -0000	[thread overview]
Message-ID: <4218AA55.7080304@gnu.org> (raw)
In-Reply-To: <20050219000623.GA9877@white>

Bob Rossi wrote:
> On Fri, Feb 18, 2005 at 02:27:24PM -0500, Alain Magloire wrote:
> 
>>>>Ok.  Wonder if it should be ``set/show tty'', "tty ..." just a wrapper.
>>>
>>>Ok, I'm going to implement this before even thinking about anything
>>>else. Do you care what file the -mi-tty command's go in? or should I
>>>create a new file?
>>>
>>>Also, is there an easy way to use the set/show internally to GDB? This
>>>way, as you suggessted, there will be 3 ways to access the inferior's
>>>tty device name.
>>>
>>>   - through the MI commands
>>>   - through the set/show
>>>   - and you can only set the tty through the 'tty' console command
>>>     there is no way to get the name. This should probably be
>>>     depricated ...
>>>
>>>Internally, they should all use the same data, so, is there an
>>>interface to modify the set/show value internally to GDB?
>>>
>>
>>Bob,
>>  I did not see the original of your proposal, so ..
>>Am I correct to assume that the "show" tty will print the master side
>>and not the slave or vice versa ...
>>Meaning the frontends are interested in the other side of the pipe
>>not the tty given by gdb to the inferior.
> 
> 
> Hi Alain,
> 
> There are 2 different ideas being suggested, 
>    - To create an mi command, that does the same thing as the console
>      'tty' command, and each of these internally can be wrappers around
>      some data that can be accessed with GDB's set/show mechanism. For
>      example,
>         -mi-set-tty /dev/pts/1 (mi command)
>         tty /dev/pts/1         (console command)
>         set tty /dev/pts/1     (set command)

and I belive:
	set tty
I need to confirm it but it appears that there's an ``optional 
filename'' class of variable (grep for filename_completer in the sources).

If the last is implemented, an existing MI command should already let 
you set/show the variable.

>    - The second idea was to have GDB internally create a pty. That would
>      result in a master and slave side. Neither of these are important,
>      AFAIK, only the slavename (file name of the terminal created, 
>      ie. /dev/pts/1) is important. For example, here is what could
>      happen
>       1. The user asks GDB to open a new pty and the name is given back
>       -mi-create-pty
>       /dev/pts/1
>       2. The user asks GDB to use that pty for the inferior
>       -mi-set-tty /dev/pts/1
>       3. The user opens /dev/pts/1 in there own program to read the
>       output of the inferior.
>       4. The user asks GDB to close the device
>       -mi-destroy-pty /dev/pts/1
> 
> Either way, it will probably be a while before I have time to work on
> the second task, since I'm already swamped trying to validate the MI
> testsuite with a syntax checker and changing the grammar to match
> what GDB actually outputs.

Andrew


  reply	other threads:[~2005-02-20 15:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-10 15:43 Bob Rossi
2005-02-10 17:43 ` Andrew Cagney
2005-02-10 18:16   ` Bob Rossi
2005-02-10 19:58     ` Andrew Cagney
2005-02-10 23:34       ` Bob Rossi
2005-02-11  4:01         ` Andrew Cagney
2005-02-11 19:07           ` Bob Rossi
2005-02-12  3:13             ` Andrew Cagney
2005-02-12 10:59               ` Bob Rossi
2005-02-15 15:07                 ` Bob Rossi
2005-02-16 20:03                   ` Andrew Cagney
2005-02-17  0:28                     ` Bob Rossi
2005-02-17 13:51                       ` Daniel Jacobowitz
2005-02-17 16:58                       ` Andrew Cagney
2005-02-17 20:09                         ` Alain Magloire
     [not found]                         ` <200502171658.LAA02386@smtp.ott.qnx.com>
2005-02-18  2:46                           ` Bob Rossi
2005-02-18 12:10                         ` Nick Roberts
2005-02-18 19:51                         ` Bob Rossi
2005-02-18 21:05                           ` Alain Magloire
2005-02-19 23:51                             ` Bob Rossi
2005-02-21  2:12                               ` Andrew Cagney [this message]
2005-02-22 23:24                                 ` Alain Magloire
     [not found]                                 ` <200502221635.LAA07270@smtp.ott.qnx.com>
2005-03-01  2:40                                   ` Bob Rossi
2005-03-01 15:14                                     ` Bob Rossi
2005-03-01 19:24                                       ` Alain Magloire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4218AA55.7080304@gnu.org \
    --to=cagney@gnu.org \
    --cc=alain@qnx.com \
    --cc=bob@brasko.net \
    --cc=gdb-patches@sources.redhat.com \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox