Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] CDT debug and ptys

On 10 Sep 2002, Tom Tromey wrote:

> My understanding is that, unfortunately, there is not currently a
> portable way to do this.  Also I believe that long term the answer is
> to run gdb in async mode, and then ask gdb to interrupt the inferior.
> I'm given to believe that async doesn't work in all situations; Keith
> and Elena really would have to comment on that.  Hopefully they're
> reading and can speak to it.

Yes, that would be our next big task: asyncing the Linux native. This 
should get us one step closer to fixing two major problems: interrupting 
the inferior and simple I/O from the inferior.
 
> Alain> But Windows is still a problem, not sure what -tty means for
> Alain> Cygwin/gdb.

It doesn't mean anything -- on cygwin native, the tty creation stuff is 
all skipped. (It's all in fork-child.c, which is not compiled into
cygwin-targeted gdbs.)

> Alain> The xterm solution, you are proposing above will not work for
> Alain> windows either.
> 
> True.  It seems unlikely to me that a really portable solution will be
> found here.

I don't think you have a choice on windows (not with cygwin, at least). 
You are either going to get a console window (if the app was compiled with 
-Wl,--subsystem,console) or you are always not going to get it 
(-Wl,--subsystem,windows). I don't think this last case matters too much, 
since --subsystem,windows will not have any std*. In Insight, we consider 
cygwin to be a freebie in this regard.
 
> Alain> Question: how do you get the xterm's tty? Are we talking JNI
> Alain> code or is there some xterm/shell hackery to find the tty
> Alain> portably.
> 
> There is hackery, but it doesn't require any new native code.

IMO, this is the way to do this. It (appears to) work on all unices. 
(Well, at least I've never had someone tell me that it doesn't work!)

> Alain> For application like vi etc .. the long term solution is
> Alain> probably to provide a Terminal Emulation.
> 
> Ouch.

Double ouch. [Hmmm.. I don't think MI's output streams handle non-ASCII 
characters very well. If the CDT ever does do this, we'll probably have to 
"correct" this.]

Keith



Back to the top