invoking GDB from FE and signals

invoking GDB from FE and signals

[Bob Rossi]

Hi,

Does anyone know the correct way to invoke GDB from a front end. I know
it's possible to use either a PTY or a pipe. By using the PTY, readline
is between the FE and GDB. By using a pipe, readline is not used. Of
course, I'm still using annotate=2 here, not gdb/mi which doesn't
support readline either way.

For a long time, using many different GDB's I've started GDB using a
pipe, thinking readline wasn't necessary. Now I have run into a bad
problem. This difference is important, because I believe GDB handles
signals slightly different when readline is on the terminal or not.

When my FE receives a ^c on the terminal, I need to send that to GDB.
For a long time I have sent a 'kill (gdb_pid, SIGINT)' to GDB to
accomplish this task. This has worked well for me, and I use this
technique for SIGINT, SIGTERM and SIGQUIT. 

I recently had someone report to me that when my FE is started on a Mac
and ^c is entered, I send the signal to GDB and it responds with
"(Quit)" as expected. However, if GDB is running the inferior, and ^c is
received, I send the 'kill' and GDB shuts down. It was reported that
when the user just used GDB, both of these case's worked as expected. Of
course, the major difference is that readline was used with just GDB and
when using my FE, no readline was available when GDB received the
signal.

Is there a better way for the FE to send this data to GDB? Is this a bug
in GDB? Do I need to start GDB with readline between the FE and it?

Finally, this should be documented and tested (which I'll be glad to do). 
Especially since when using the MI interface, readline will never be
available to be between GDB and the FE if started with a PTY or a pipe.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Sat, May 13, 2006 at 10:19:20AM -0400, Bob Rossi wrote:
> I recently had someone report to me that when my FE is started on a Mac
> and ^c is entered, I send the signal to GDB and it responds with
> "(Quit)" as expected. However, if GDB is running the inferior, and ^c is
> received, I send the 'kill' and GDB shuts down.

Then I'm afraid you need to work out why that happened; speculating
about it is not going to get you much of anywhere.  It depends on e.g.
job control.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sat, May 13, 2006 at 10:54:22AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 13, 2006 at 10:19:20AM -0400, Bob Rossi wrote:
> > I recently had someone report to me that when my FE is started on a Mac
> > and ^c is entered, I send the signal to GDB and it responds with
> > "(Quit)" as expected. However, if GDB is running the inferior, and ^c is
> > received, I send the 'kill' and GDB shuts down.
> 
> Then I'm afraid you need to work out why that happened; speculating
> about it is not going to get you much of anywhere.  It depends on e.g.
> job control.

OK, I can find out the details. However, I'm thinking the supported way
of starting GDB from a FE is via a pipe. This would prevent readline
from being in the way, and is the only way to do it with MI anyways,
right?

Actually, having a PTY between the FE and GDB/MI would be slightly
different than a pipe. It would make it so the user could never send
certain chars to GDB without them being interpreted by the PTY.

In other words, I don't mind finding the details, but I'd like to make
sure I'm doing it the correct way first.

Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Sat, May 13, 2006 at 11:10:26AM -0400, Bob Rossi wrote:
> OK, I can find out the details. However, I'm thinking the supported way
> of starting GDB from a FE is via a pipe. This would prevent readline
> from being in the way, and is the only way to do it with MI anyways,
> right?

There's no such thing as "the supported way".

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sat, May 13, 2006 at 11:10:57AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 13, 2006 at 11:10:26AM -0400, Bob Rossi wrote:
> > OK, I can find out the details. However, I'm thinking the supported way
> > of starting GDB from a FE is via a pipe. This would prevent readline
> > from being in the way, and is the only way to do it with MI anyways,
> > right?
> 
> There's no such thing as "the supported way".

hmmm, I do get frustrated with my inability to communicate on this
mailint list.

When I say "the supported way", I'm assuming there is a way GDB provides
for FE's to work with it in regards to sending signals, in particularly
^c. If GDB doesn't provide this functionality and it's mere hackers
chance that all of us FE's are getting this to work most of the time,
then I understand what you mean.

Othewise, if GDB has been designed to accept signal during certain
circumstances, and not during others, I would love to know what those
are so that I can benefit from using this functionality.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Sat, May 13, 2006 at 11:20:21AM -0400, Bob Rossi wrote:
> When I say "the supported way", I'm assuming there is a way GDB provides
> for FE's to work with it in regards to sending signals, in particularly
> ^c.

But there isn't :-)

> If GDB doesn't provide this functionality and it's mere hackers
> chance that all of us FE's are getting this to work most of the time,
> then I understand what you mean.
> 
> Othewise, if GDB has been designed to accept signal during certain
> circumstances, and not during others, I would love to know what those
> are so that I can benefit from using this functionality.

If there were such a design, hopefully, it would be in the manual.  All
of this is generally legacy from the GDB CLI, which is designed to work
with the host's job control.  When the inferior is running and you
press Control-C, the signal goes to the inferior, not to GDB.

Your needs may be different.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sat, May 13, 2006 at 11:48:16AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 13, 2006 at 11:20:21AM -0400, Bob Rossi wrote:
> > When I say "the supported way", I'm assuming there is a way GDB provides
> > for FE's to work with it in regards to sending signals, in particularly
> > ^c.
> 
> But there isn't :-)
> 
> > If GDB doesn't provide this functionality and it's mere hackers
> > chance that all of us FE's are getting this to work most of the time,
> > then I understand what you mean.
> > 
> > Othewise, if GDB has been designed to accept signal during certain
> > circumstances, and not during others, I would love to know what those
> > are so that I can benefit from using this functionality.
> 
> If there were such a design, hopefully, it would be in the manual.  All
> of this is generally legacy from the GDB CLI, which is designed to work
> with the host's job control.  When the inferior is running and you
> press Control-C, the signal goes to the inferior, not to GDB.
> 
> Your needs may be different.

Nick,

Would you mind posting how Emacs starts up GDB both in annotate mode and
in mi mode? Does it use a pty or pipe?

Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
stdin? or does it use 'kill(gdb_pid, SIGINT)'?

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Nick Roberts]

 > Nick,
 > 
 > Would you mind posting how Emacs starts up GDB both in annotate mode and
 > in mi mode? Does it use a pty or pipe?
--text follows this line--
I'm not too familiar with the low level stuff.  My understanding (Eli might
correct me) is that Emacs always create a pty if possible and uses a pipe
otherwise (I've not experienced the latter).

It doesn't use readline, probably because the terminal can't have the required
characteristics (Emacs controls all keyboard input) but simulates it through
GDB's complete command that was written especially for Emacs

 > Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
 > stdin? or does it use 'kill(gdb_pid, SIGINT)'?

Emacs uses ^c for other purposes (as a prefix key).  I guess you mean "what
does it do when SIGINT is read" (which is sent by ~c^c).  Well it just works
like it does in a terminal but then I was surprised when Daniel said:

    When the inferior is running and you press Control-C, the signal goes to
    the inferior, not to GDB.

because I had thought it was the other way round and GDB could decide whether
to pass the signal on to the inferior or not according to the output of
"info signal".


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: invoking GDB from FE and signals

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 14 May 2006 09:57:00 +1200
> Cc: gdb@sourceware.org
> 
> I'm not too familiar with the low level stuff.  My understanding (Eli might
> correct me) is that Emacs always create a pty if possible and uses a pipe
> otherwise

This is true.  Pipes are generally used only on Windows.

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Sun, May 14, 2006 at 09:57:00AM +1200, Nick Roberts wrote:
> does it do when SIGINT is read" (which is sent by ~c^c).  Well it just works
> like it does in a terminal but then I was surprised when Daniel said:
> 
>     When the inferior is running and you press Control-C, the signal goes to
>     the inferior, not to GDB.
> 
> because I had thought it was the other way round and GDB could decide whether
> to pass the signal on to the inferior or not according to the output of
> "info signal".

Job control signals are funny.  The C-c sends a signal to the process
group in control of the current terminal, and when the inferior is
running, GDB makes sure that it "owns" the terminal (so that it won't
e.g. be automatically stopped with SIGTTIN if it tries to read()).

This all predates 'set tty' of course.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Nick Roberts]

 > Job control signals are funny.  The C-c sends a signal to the process
 > group in control of the current terminal, and when the inferior is
 > running, GDB makes sure that it "owns" the terminal (so that it won't
 > e.g. be automatically stopped with SIGTTIN if it tries to read()).

Maybe that relates to what I'm seeing on the async branch (and with Apple's
GDB) where the inferior can't accept input on the same terminal:

  -exec-run
  ^running
  (gdb)
  Enter value for n1: 5
  Enter value for n2:
  Suspended (tty input)

Where 5 has been entered by the user for the inferior.

I was hoping that GDB could tell whether the inferior was waiting for input or
not and pass any input it receives or process it accordingly (a problem I
have with Emacs is not knowing whether to queue an input for GDB or send
it immediately for the inferior).


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 10:37:33AM +1200, Nick Roberts wrote:
> Maybe that relates to what I'm seeing on the async branch (and with Apple's
> GDB) where the inferior can't accept input on the same terminal:
> 
>   -exec-run
>   ^running
>   (gdb)
>   Enter value for n1: 5
>   Enter value for n2:
>   Suspended (tty input)
> 
> Where 5 has been entered by the user for the inferior.

Correct.  This is managed by target_terminal_ours and
target_terminal_inferior.

> I was hoping that GDB could tell whether the inferior was waiting for input or
> not and pass any input it receives or process it accordingly (a problem I
> have with Emacs is not knowing whether to queue an input for GDB or send
> it immediately for the inferior).

The inferior's stdin is connected to the terminal, not to GDB, so
there's no way to do this.  Basically, if they're both going to read
from the same standard input, "synchronous" operation is pretty much
mandated.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> Would you mind posting how Emacs starts up GDB both in annotate mode and
> in mi mode? Does it use a pty or pipe?
>
> Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
> stdin? or does it use 'kill(gdb_pid, SIGINT)'?

The Emacs Lisp 'start-process' function, which is what the GDB mode
and other shell modes use, creates a pseudo-tty by default (when
available).  You can dynamically bind process-connection-type while
calling it to get pipes if you want.

When the process is communicating with Emacs via a pipe, Emacs sends
signals to it with 'kill'.  When the process is using a pseudo-tty,
Emacs uses an ioctl on the master side to get the effect of the user
hitting C-c, but in a way that works even if the program has changed
the tty settings.  I think at one point Emacs actually fetched the
'intr' character from the tty's settings, and stuffed that character
into the master side, letting the tty driver generate the signal.  But
you want to get the tty device involved somehow, so that the signal
will go to the tty's current process group.


(That was all so long ago...)

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sun, May 14, 2006 at 12:16:53AM -0400, Daniel Jacobowitz wrote:
> On Sun, May 14, 2006 at 09:57:00AM +1200, Nick Roberts wrote:
> > does it do when SIGINT is read" (which is sent by ~c^c).  Well it just works
> > like it does in a terminal but then I was surprised when Daniel said:
> > 
> >     When the inferior is running and you press Control-C, the signal goes to
> >     the inferior, not to GDB.
> > 
> > because I had thought it was the other way round and GDB could decide whether
> > to pass the signal on to the inferior or not according to the output of
> > "info signal".
> 
> Job control signals are funny.  The C-c sends a signal to the process
> group in control of the current terminal, and when the inferior is
> running, GDB makes sure that it "owns" the terminal (so that it won't
> e.g. be automatically stopped with SIGTTIN if it tries to read()).
> 
> This all predates 'set tty' of course.

O, right. The tty command. I definatly use that for the inferior which I
believe emacs does not. Nick, do you know if emacs uses the 'set tty'
command?

Daniel, can you think of how this would effect signal handling? In
particular the 'kill (gdb_pid, SIGINT)' I send to GDB, only when the
inferior is running, shuts down GDB. This could of course be because the
inferior is dieing. What do you think?

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sun, May 14, 2006 at 11:55:10PM -0700, Jim Blandy wrote:
> 
> Bob Rossi <bob_rossi@cox.net> writes:
> > Would you mind posting how Emacs starts up GDB both in annotate mode and
> > in mi mode? Does it use a pty or pipe?
> >
> > Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
> > stdin? or does it use 'kill(gdb_pid, SIGINT)'?
> 
> The Emacs Lisp 'start-process' function, which is what the GDB mode
> and other shell modes use, creates a pseudo-tty by default (when
> available).  You can dynamically bind process-connection-type while
> calling it to get pipes if you want.

Hey Jim, thanks for the info! The user that's having the problem with my
FE states that emacs works fine. So, are you suggesting I could have him
put some configuration line with regards to 'process-connection-type' to
get emacs to use a pipe instead of a pty? If so, it would be perfect to
see emacs also produce the same bug that my FE is producing. Do you know
the exact line that he could add to a particular file in order to get
emacs working like this?

> When the process is communicating with Emacs via a pipe, Emacs sends
> signals to it with 'kill'.  When the process is using a pseudo-tty,
> Emacs uses an ioctl on the master side to get the effect of the user
> hitting C-c, but in a way that works even if the program has changed
> the tty settings.  I think at one point Emacs actually fetched the
> 'intr' character from the tty's settings, and stuffed that character
> into the master side, letting the tty driver generate the signal.  But
> you want to get the tty device involved somehow, so that the signal
> will go to the tty's current process group.
> 
> 
> (That was all so long ago...)

Wow, this information is amazingly helpful. I do the same solution emacs
is doing with regards to pipe's. I used to actually do the pty solution.
I'm considering adding an option also, to allow using both solutions.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 09:35:36AM -0400, Bob Rossi wrote:
> Daniel, can you think of how this would effect signal handling?

Not at all.  You really need to figure out what's going on yourself;
there's too many variables and I've never run GDB in any of the ways
you're talking about.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[PAUL GILLIAM]

On Sat, 2006-05-13 at 11:48 -0400, Daniel Jacobowitz wrote:
> On Sat, May 13, 2006 at 11:20:21AM -0400, Bob Rossi wrote:
> > When I say "the supported way", I'm assuming there is a way GDB provides
> > for FE's to work with it in regards to sending signals, in particularly
> > ^c.
> 
> But there isn't :-)
> 
> > If GDB doesn't provide this functionality and it's mere hackers
> > chance that all of us FE's are getting this to work most of the time,
> > then I understand what you mean.
> > 
> > Othewise, if GDB has been designed to accept signal during certain
> > circumstances, and not during others, I would love to know what those
> > are so that I can benefit from using this functionality.
> 
> If there were such a design, hopefully, it would be in the manual.  All
> of this is generally legacy from the GDB CLI, which is designed to work
> with the host's job control.  When the inferior is running and you
> press Control-C, the signal goes to the inferior, not to GDB.
> 
> Your needs may be different.

Just to add a little detail about the 'normal' case:  You press
<cntl-c>, the tty handler intercepts it and sends a signal to the
inferior.  Because the inferior is being debugged, *any* signal causes
it to stop, letting the debugger know that it stopped due to a
particular signal.  When gdb causes the inferior to run again, gdb
decides if the signal should be 'passed through' to the inferior'.

I hope I'm not being pedantic.

-=# Paul #=-

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> On Sun, May 14, 2006 at 11:55:10PM -0700, Jim Blandy wrote:
>> 
>> Bob Rossi <bob_rossi@cox.net> writes:
>> > Would you mind posting how Emacs starts up GDB both in annotate mode and
>> > in mi mode? Does it use a pty or pipe?
>> >
>> > Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
>> > stdin? or does it use 'kill(gdb_pid, SIGINT)'?
>> 
>> The Emacs Lisp 'start-process' function, which is what the GDB mode
>> and other shell modes use, creates a pseudo-tty by default (when
>> available).  You can dynamically bind process-connection-type while
>> calling it to get pipes if you want.
>
> Hey Jim, thanks for the info! The user that's having the problem with my
> FE states that emacs works fine. So, are you suggesting I could have him
> put some configuration line with regards to 'process-connection-type' to
> get emacs to use a pipe instead of a pty? If so, it would be perfect to
> see emacs also produce the same bug that my FE is producing. Do you know
> the exact line that he could add to a particular file in order to get
> emacs working like this?

I think if you switch from a pty to a pipe, there will be lots of
different changes in the behavior of the subprocess.  You might get
behavior like what your front end shows, but you might not even get
that far.  Or there might be other confusing things going on.

You could put

(setq process-connection-type nil)

in your .emacs file.  But only use this for testing!  Take it out when
you're done.  process-connection-type is meant to be used in
combination with Emacs Lisp's dynamic binding; if you just whack its
value globally you'll get all sorts of wierd behavior from anything
that tries to run a subprocess from a pty.

> Wow, this information is amazingly helpful. I do the same solution emacs
> is doing with regards to pipe's. I used to actually do the pty solution.
> I'm considering adding an option also, to allow using both solutions.

If you're not familiar with how job control works, and how it
interacts with tty devices, you should definitely read up on that.  If
you're not interacting with the tty in a way that plays nicely with
GDB's tty management code, then you'll have all sorts of problems like
this.

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> On Sun, May 14, 2006 at 12:16:53AM -0400, Daniel Jacobowitz wrote:
>> On Sun, May 14, 2006 at 09:57:00AM +1200, Nick Roberts wrote:
>> > does it do when SIGINT is read" (which is sent by ~c^c).  Well it just works
>> > like it does in a terminal but then I was surprised when Daniel said:
>> > 
>> >     When the inferior is running and you press Control-C, the signal goes to
>> >     the inferior, not to GDB.
>> > 
>> > because I had thought it was the other way round and GDB could decide whether
>> > to pass the signal on to the inferior or not according to the output of
>> > "info signal".
>> 
>> Job control signals are funny.  The C-c sends a signal to the process
>> group in control of the current terminal, and when the inferior is
>> running, GDB makes sure that it "owns" the terminal (so that it won't
>> e.g. be automatically stopped with SIGTTIN if it tries to read()).
>> 
>> This all predates 'set tty' of course.
>
> O, right. The tty command. I definatly use that for the inferior which I
> believe emacs does not. Nick, do you know if emacs uses the 'set tty'
> command?

When you use GDB in the normal way, 'M-x gdb', it doesn't.

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 10:07:51AM -0700, PAUL GILLIAM wrote:
> On Sat, 2006-05-13 at 11:48 -0400, Daniel Jacobowitz wrote:
> > On Sat, May 13, 2006 at 11:20:21AM -0400, Bob Rossi wrote:
> > > When I say "the supported way", I'm assuming there is a way GDB provides
> > > for FE's to work with it in regards to sending signals, in particularly
> > > ^c.
> > 
> > But there isn't :-)
> > 
> > > If GDB doesn't provide this functionality and it's mere hackers
> > > chance that all of us FE's are getting this to work most of the time,
> > > then I understand what you mean.
> > > 
> > > Othewise, if GDB has been designed to accept signal during certain
> > > circumstances, and not during others, I would love to know what those
> > > are so that I can benefit from using this functionality.
> > 
> > If there were such a design, hopefully, it would be in the manual.  All
> > of this is generally legacy from the GDB CLI, which is designed to work
> > with the host's job control.  When the inferior is running and you
> > press Control-C, the signal goes to the inferior, not to GDB.
> > 
> > Your needs may be different.
> 
> Just to add a little detail about the 'normal' case:  You press
> <cntl-c>, the tty handler intercepts it and sends a signal to the
> inferior.  Because the inferior is being debugged, *any* signal causes
> it to stop, letting the debugger know that it stopped due to a
> particular signal.  When gdb causes the inferior to run again, gdb
> decides if the signal should be 'passed through' to the inferior'.
> 
> I hope I'm not being pedantic.

OK, here's what happens from the FE perspective though. You type ^c. The
FE get's the signal (which is in a different process group than GDB),
and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.

Even though the inferior is running, GDB is getting the signal. What
happens from this point? Also, the 2 interesting case's might be when
the inferior is on the same PTY as GDB and on a different PTY.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> OK, here's what happens from the FE perspective though. You type ^c. The
> FE get's the signal (which is in a different process group than GDB),
> and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.

Jim just explained this, but it may not have been clear: that is the
wrong way to forward the signal.  If you are running GDB on a
pseudo-tty, you need to forward the job control signal to that TTY, not
to the GDB process itself.

I don't really know how to do that.  Is it by setting BRKING in
termios?  There's something about TIOCSIGNAL too.  Lots of code for
this in emacs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > OK, here's what happens from the FE perspective though. You type ^c. The
> > FE get's the signal (which is in a different process group than GDB),
> > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> 
> Jim just explained this, but it may not have been clear: that is the
> wrong way to forward the signal.  If you are running GDB on a
> pseudo-tty, you need to forward the job control signal to that TTY, not
> to the GDB process itself.
> 
> I don't really know how to do that.  Is it by setting BRKING in
> termios?  There's something about TIOCSIGNAL too.  Lots of code for
> this in emacs.

I'm totally confused. I'm certainly not an expert, but sending a signal
can only be done to a pid using kill. What other ways are there?

Bob Rossi

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sun, May 14, 2006 at 11:55:10PM -0700, Jim Blandy wrote:
> 
> Bob Rossi <bob_rossi@cox.net> writes:
> > Would you mind posting how Emacs starts up GDB both in annotate mode and
> > in mi mode? Does it use a pty or pipe?
> >
> > Also, what does it do when ^c is read? Does it 'write' the byte to GDB's
> > stdin? or does it use 'kill(gdb_pid, SIGINT)'?
> 
> The Emacs Lisp 'start-process' function, which is what the GDB mode
> and other shell modes use, creates a pseudo-tty by default (when
> available).  You can dynamically bind process-connection-type while
> calling it to get pipes if you want.
> 
> When the process is communicating with Emacs via a pipe, Emacs sends
> signals to it with 'kill'.  When the process is using a pseudo-tty,
> Emacs uses an ioctl on the master side to get the effect of the user
> hitting C-c, but in a way that works even if the program has changed
> the tty settings.  I think at one point Emacs actually fetched the
> 'intr' character from the tty's settings, and stuffed that character
> into the master side, letting the tty driver generate the signal.  But
> you want to get the tty device involved somehow, so that the signal
> will go to the tty's current process group.
> 
> 
> (That was all so long ago...)

Jim, Thanks! You helped solve the problem. The user initially reported
that sending ^c to the FE while the inferior was running would cause GDB
to shut down. 

I asked the user to try emacs, and he reported that this worked fine. 
After finding out about process-connection-type, I asked him to set 
that to nil. The user told me that emacs also causes GDB to shut down 
when sending ^c to emacs while the inferior is running.

So, now that I know what the problem is, I'll fix it on my end. However,
could this be a potential GDB bug? or is this intended functionality?
If it's thought to be a bug, I could get the latest GDB built on that
system to see the behavior.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 03:43:14PM -0400, Bob Rossi wrote:
> On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > FE get's the signal (which is in a different process group than GDB),
> > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > 
> > Jim just explained this, but it may not have been clear: that is the
> > wrong way to forward the signal.  If you are running GDB on a
> > pseudo-tty, you need to forward the job control signal to that TTY, not
> > to the GDB process itself.
> > 
> > I don't really know how to do that.  Is it by setting BRKING in
> > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > this in emacs.
> 
> I'm totally confused. I'm certainly not an expert, but sending a signal
> can only be done to a pid using kill. What other ways are there?

Read it again :-)

You don't want to send the signal to a specific process.  You want to
cause the pseudo-terminal to signal the correct process group.

(Also, process group != pid; you can kill negative pids, see a POSIX
reference).

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[PAUL GILLIAM]

On Mon, 2006-05-15 at 15:43 -0400, Bob Rossi wrote:
> On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > FE get's the signal (which is in a different process group than GDB),
> > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > 
> > Jim just explained this, but it may not have been clear: that is the
> > wrong way to forward the signal.  If you are running GDB on a
> > pseudo-tty, you need to forward the job control signal to that TTY, not
> > to the GDB process itself.
> > 
> > I don't really know how to do that.  Is it by setting BRKING in
> > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > this in emacs.
> 
> I'm totally confused. I'm certainly not an expert, but sending a signal
> can only be done to a pid using kill. What other ways are there?
> 
> Bob Rossi

Two things:
1) Yes the only way to send a signal to a *pid* is with kill.  But which
pid?  DO NOT SEND THE SIGNAL TO GDB!  Send it to GDB's inferior.  
2) Danial is not asking you to send a signal to a pty, he is asking you
to send a signal to GDB's inferior *via* the pty, by using an ioctl
function and suggesting that code exists in EMACS to do just that.

-=# Paul #=-

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 04:05:47PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 15, 2006 at 03:43:14PM -0400, Bob Rossi wrote:
> > On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > > FE get's the signal (which is in a different process group than GDB),
> > > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > > 
> > > Jim just explained this, but it may not have been clear: that is the
> > > wrong way to forward the signal.  If you are running GDB on a
> > > pseudo-tty, you need to forward the job control signal to that TTY, not
> > > to the GDB process itself.
> > > 
> > > I don't really know how to do that.  Is it by setting BRKING in
> > > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > > this in emacs.
> > 
> > I'm totally confused. I'm certainly not an expert, but sending a signal
> > can only be done to a pid using kill. What other ways are there?
> 
> Read it again :-)
> 
> You don't want to send the signal to a specific process.  You want to
> cause the pseudo-terminal to signal the correct process group.
> 
> (Also, process group != pid; you can kill negative pids, see a POSIX
> reference).

OK, here's the problem. There are 2 case's, using a PTY or not.

I am currently not using a PTY. So, I send the signal via kill. Is this
correct or incorrect?

If I use a PTY, which I'm going to have to reimplement. I'll except
signals like SIGINT, cause I'll forward them with 'write' to the PTY
between GDB and CGDB. 

I think this was Jim's idea of how Emacs works, and it's what I would
think would be best.

Bob Rossi

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 12:05:22PM -0700, PAUL GILLIAM wrote:
> On Mon, 2006-05-15 at 15:43 -0400, Bob Rossi wrote:
> > On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > > FE get's the signal (which is in a different process group than GDB),
> > > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > > 
> > > Jim just explained this, but it may not have been clear: that is the
> > > wrong way to forward the signal.  If you are running GDB on a
> > > pseudo-tty, you need to forward the job control signal to that TTY, not
> > > to the GDB process itself.
> > > 
> > > I don't really know how to do that.  Is it by setting BRKING in
> > > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > > this in emacs.
> > 
> > I'm totally confused. I'm certainly not an expert, but sending a signal
> > can only be done to a pid using kill. What other ways are there?
> > 
> > Bob Rossi
> 
> Two things:
> 1) Yes the only way to send a signal to a *pid* is with kill.  But which
> pid?  DO NOT SEND THE SIGNAL TO GDB!  Send it to GDB's inferior.  

haha. See, pedantic is good. I'm catching on. Now, please forgive me for
asking. Is it as easy as sending the signal to the inferior all the
time? or do I need to send it to the inferior when it is running, or to
GDB when it is running?

and is that why it's better to somehow send it to the PTY? I'm thinking
just writing the ^c to the PTY is the best solution, since it will
handle all of this for me.

> 2) Danial is not asking you to send a signal to a pty, he is asking you
> to send a signal to GDB's inferior *via* the pty, by using an ioctl
> function and suggesting that code exists in EMACS to do just that.

Whoa, that's interesting.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 04:10:06PM -0400, Bob Rossi wrote:
> OK, here's the problem. There are 2 case's, using a PTY or not.
> 
> I am currently not using a PTY. So, I send the signal via kill. Is this
> correct or incorrect?

I have no idea how to get this right for the pipe case.  Maybe someone
else does.

> If I use a PTY, which I'm going to have to reimplement. I'll except
> signals like SIGINT, cause I'll forward them with 'write' to the PTY
> between GDB and CGDB. 

I don't think "write" will do it; you need something more complicated.
Maybe I'm wrong and writing the interrupt character will do it.

GDB expects, today, to have a console.  It expects C-c to go to the
foreground process group on that console.  It arranges to be the
foreground process when GDB is stopped, and for the inferior to be in
the foreground when it is running.

This may not be the most useful behavior for your case.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 04:20:42PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 15, 2006 at 04:10:06PM -0400, Bob Rossi wrote:
> > OK, here's the problem. There are 2 case's, using a PTY or not.
> > 
> > I am currently not using a PTY. So, I send the signal via kill. Is this
> > correct or incorrect?
> 
> I have no idea how to get this right for the pipe case.  Maybe someone
> else does.

Yeah, it appears both emacs and CGDB get this wrong for the pipe case,
as they both loose GDB when ^c is typed. I wonder if this is a bug or
simply impossible ...

> > If I use a PTY, which I'm going to have to reimplement. I'll except
> > signals like SIGINT, cause I'll forward them with 'write' to the PTY
> > between GDB and CGDB. 
> 
> I don't think "write" will do it; you need something more complicated.
> Maybe I'm wrong and writing the interrupt character will do it.

I desire that CGDB works exactly the same as if the user was at the
terminal with GDB. So, ^c probably is what I want, since it's what 
the user would have to do anyways. Does this sound correct to you?

Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Mon, May 15, 2006 at 04:34:26PM -0400, Bob Rossi wrote:
> > > If I use a PTY, which I'm going to have to reimplement. I'll except
> > > signals like SIGINT, cause I'll forward them with 'write' to the PTY
> > > between GDB and CGDB. 
> > 
> > I don't think "write" will do it; you need something more complicated.
> > Maybe I'm wrong and writing the interrupt character will do it.
> 
> I desire that CGDB works exactly the same as if the user was at the
> terminal with GDB. So, ^c probably is what I want, since it's what 
> the user would have to do anyways. Does this sound correct to you?

The interrupt character is actually configurable; C-c might not
generate an interrupt, et cetera.  All this stuff is very complex :-)

(man stty, search for intr)

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 05:02:46PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 15, 2006 at 04:34:26PM -0400, Bob Rossi wrote:
> > > > If I use a PTY, which I'm going to have to reimplement. I'll except
> > > > signals like SIGINT, cause I'll forward them with 'write' to the PTY
> > > > between GDB and CGDB. 
> > > 
> > > I don't think "write" will do it; you need something more complicated.
> > > Maybe I'm wrong and writing the interrupt character will do it.
> > 
> > I desire that CGDB works exactly the same as if the user was at the
> > terminal with GDB. So, ^c probably is what I want, since it's what 
> > the user would have to do anyways. Does this sound correct to you?
> 
> The interrupt character is actually configurable; C-c might not
> generate an interrupt, et cetera.  All this stuff is very complex :-)
> 
> (man stty, search for intr)

Thanks, I've spent a lot of time dealing with this in the past. A good
primer for me was Advanced Programming in the UNIX Environment, written
by W Richard Stevens.

Unless an example can be given otherwise, I think writing the char to
the PTY is the best solution. This provides hopefully the exact same
response the user would get while sitting in front of the PTY. However,
you recomendation alerts me that I will need to make sure that the
created PTY has the same values set as the PTY on CGDB's STDIN.

Hopefully, I'll have some solution soon. I think this is a wealth of
information, would all of these details be welcome in the MI manual,
under "Starting and controlling GDB"?

Thanks a lot,
Bob Rossi

Re: invoking GDB from FE and signals

[Joel Brobecker]

> > 2) Danial is not asking you to send a signal to a pty, he is asking you
> > to send a signal to GDB's inferior *via* the pty, by using an ioctl
> > function and suggesting that code exists in EMACS to do just that.
> 
> Whoa, that's interesting.

Just for FYI, GPS simple reused the code from Emacs, and it works great.
We where able to port it to new unix architectures with minimal amounts
or changes. So I would suggest trying to replace your code that uses
pipes, use the emacs code plugged in instead, and see where that gets
you. We have no problem sending interrupt events to GDB, even on Windows
and MacOS.

-- 
Joel

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 12:05:22PM -0700, PAUL GILLIAM wrote:
> On Mon, 2006-05-15 at 15:43 -0400, Bob Rossi wrote:
> > On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > > FE get's the signal (which is in a different process group than GDB),
> > > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > > 
> > > Jim just explained this, but it may not have been clear: that is the
> > > wrong way to forward the signal.  If you are running GDB on a
> > > pseudo-tty, you need to forward the job control signal to that TTY, not
> > > to the GDB process itself.
> > > 
> > > I don't really know how to do that.  Is it by setting BRKING in
> > > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > > this in emacs.
> > 
> > I'm totally confused. I'm certainly not an expert, but sending a signal
> > can only be done to a pid using kill. What other ways are there?
> > 
> > Bob Rossi
> 
> Two things:
> 1) Yes the only way to send a signal to a *pid* is with kill.  But which
> pid?  DO NOT SEND THE SIGNAL TO GDB!  Send it to GDB's inferior.  

After thinking about this a little longer, I had 1 other question. See,
I'm going to put GDB on a PTY. However, I also put the inferior on it's
own PTY using 'set tty'.

In this scenario, how do I send the SIGINT? and to who? I can send it
directly to GDB using the kill system call with GDB's pid. I can send 
it to GDB's PTY using the 'write' system call or i can send it to the
inferior's PTY using the 'write' system call. Which is best?

> 2) Danial is not asking you to send a signal to a pty, he is asking you
> to send a signal to GDB's inferior *via* the pty, by using an ioctl
> function and suggesting that code exists in EMACS to do just that.

Thanks, I'm going to search for this, and I appreciate the suggestions
Daniel and Paul, if either of you have a link to the code, let me know.

Bob Rossi

Re: invoking GDB from FE and signals

[Nick Roberts]

 > > 2) Danial is not asking you to send a signal to a pty, he is asking you
 > > to send a signal to GDB's inferior *via* the pty, by using an ioctl
 > > function and suggesting that code exists in EMACS to do just that.
 > 
 > Thanks, I'm going to search for this, and I appreciate the suggestions
 > Daniel and Paul, if either of you have a link to the code, let me know.

Its all in process.c (you can download Emacs from
http://savanah.gnu.org/projects/emacs).  Its for any process that runs within
Emacs, not just GDB.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: invoking GDB from FE and signals

[Bob Rossi]

On Mon, May 15, 2006 at 12:05:22PM -0700, PAUL GILLIAM wrote:
> On Mon, 2006-05-15 at 15:43 -0400, Bob Rossi wrote:
> > On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote:
> > > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote:
> > > > OK, here's what happens from the FE perspective though. You type ^c. The
> > > > FE get's the signal (which is in a different process group than GDB),
> > > > and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'.
> > > 
> > > Jim just explained this, but it may not have been clear: that is the
> > > wrong way to forward the signal.  If you are running GDB on a
> > > pseudo-tty, you need to forward the job control signal to that TTY, not
> > > to the GDB process itself.
> > > 
> > > I don't really know how to do that.  Is it by setting BRKING in
> > > termios?  There's something about TIOCSIGNAL too.  Lots of code for
> > > this in emacs.
> > 
> > I'm totally confused. I'm certainly not an expert, but sending a signal
> > can only be done to a pid using kill. What other ways are there?
> > 
> > Bob Rossi
> 
> Two things:
> 1) Yes the only way to send a signal to a *pid* is with kill.  But which
> pid?  DO NOT SEND THE SIGNAL TO GDB!  Send it to GDB's inferior.  
> 2) Danial is not asking you to send a signal to a pty, he is asking you
> to send a signal to GDB's inferior *via* the pty, by using an ioctl
> function and suggesting that code exists in EMACS to do just that.

OK, I'm still wondering what the correct way to do this is. I came up
with 5, maybe 6 distinct case's and am not sure which one is correct.

I fork GDB on a pty. I also give the inferior it's own pty. So, there is
2 pty's. This unfortunatly, already makes things different than the user
at the terminal just using GDB.

1. I can send a kill (gdb_pid, SIGINT) to GDB, but everyone thinks that is 
   a bad idea.
2. I can do a write (gdb_in, 1, "\3") to pass the ^c character to GDB's
   stdin. 
3. I can do a write (inferior_in, 1, "\3") to pass the ^c character to the 
   inferior's stdin.
4. I can do a magic ioctl that sends a signal to GDB via GDB's pty.
5. I can do a magic ioctl that sends a signal to the inferior via the 
   inferior's pty.
6. I can possible do a magic ioctl that sends a signal to the inferior via 
   the GDB's pty.

Can someone please suggest the correct solution to this problem? 

I'm wondering if using a seperate pty for the inferior makes this not
possible all the time. For instance, with 1 pty, if GDB is running, then
it will recieve the signal, but if the inferior is running, it will
recieve the signal. With 2 pty's, does the FE need to know which is
running (the pty or inferior) in order to know where to send the signal?

This is bad, because CGDB doesn't know if GDB or the inferior is
currently running. Maybe when I finish the MI mode I'll know though.

Bob Rossi

Re: invoking GDB from FE and signals

[Bob Rossi]

On Sat, May 13, 2006 at 11:10:57AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 13, 2006 at 11:10:26AM -0400, Bob Rossi wrote:
> > OK, I can find out the details. However, I'm thinking the supported way
> > of starting GDB from a FE is via a pipe. This would prevent readline
> > from being in the way, and is the only way to do it with MI anyways,
> > right?
> 
> There's no such thing as "the supported way".

There is something else I just discovered today. I think it's rather
important. If you start GDB via a pipe, then it will not ask you
questions like
  Make breakpoint pending on future shared library load? (y or [n]) 
or 
  The program is running.  Exit anyway? (y or n) 
instead, it will just assume the answer is yes.

So, switching to a pty has other advantages that might not seem obvious
at first. This could also be documented.

Bob Rossi

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> OK, I'm still wondering what the correct way to do this is. I came up
> with 5, maybe 6 distinct case's and am not sure which one is correct.
>
> I fork GDB on a pty. I also give the inferior it's own pty. So, there is
> 2 pty's. This unfortunatly, already makes things different than the user
> at the terminal just using GDB.

Right.  It means that you need to distinguish between:
- the user typing C-c at their running program, to get back to the GDB
  prompt, and
- the user typing C-c at GDB, to interrupt it while it's doing
  something else.

I assume you mean the former; I talked about this a bit more at the
bottom.

> 2. I can do a write (gdb_in, 1, "\3") to pass the ^c character to GDB's
>    stdin. 

This would send the interrupt signal to GDB, not to the inferior.
Given my assumption, this is no good.

> 3. I can do a write (inferior_in, 1, "\3") to pass the ^c character to the 
>    inferior's stdin.

This would send SIGINT to the inferior.  GDB will catch it, and report
that the program has been interrupted.  Good.  But it's sensitive to
the terminal's 'intr' character getting re-defined.

> 4. I can do a magic ioctl that sends a signal to GDB via GDB's pty.

No good, for the same reasons 2) is no good.

> 5. I can do a magic ioctl that sends a signal to the inferior via the 
>    inferior's pty.

This would be best, as it avoids worrying about the tty 'intr'
character.  But I couldn't find this ioctl in POSIX when I looked.

> 6. I can possible do a magic ioctl that sends a signal to the inferior via 
>    the GDB's pty.

There isn't anything that I know of that does this, and I don't see
any reason to do it.

> I'm wondering if using a seperate pty for the inferior makes this not
> possible all the time. For instance, with 1 pty, if GDB is running, then
> it will recieve the signal, but if the inferior is running, it will
> recieve the signal. With 2 pty's, does the FE need to know which is
> running (the pty or inferior) in order to know where to send the signal?

Well, if you want to behave exactly the way C-c does when running GDB
directly and sharing a tty with the inferior, yes.  But is that a good
idea?  You have a FE talking to GDB; do you really want the user to be
able to interrupt that conversation?

I think you should just say, C-c interrupts the inferior, not GDB, and
go with 3) or 5).  If you can find the ioctl.  Beware, POSIX wrapped
up the ioctls in functions, so you can't just search for ioctl in
Emacs.  You'll need to follow through the definition of the
interrupt-process Emacs Lisp function (in src/process.c).

> This is bad, because CGDB doesn't know if GDB or the inferior is
> currently running. Maybe when I finish the MI mode I'll know though.

And even if you did, there'd be race conditions: you send the C-c just
as GDB is reporting that the inferior has stopped, etc.

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> On Fri, May 19, 2006 at 10:17:02AM -0700, Jim Blandy wrote:
>> 
>> Bob Rossi <bob_rossi@cox.net> writes:
>> > On Fri, May 19, 2006 at 08:49:19AM -0400, Daniel Jacobowitz wrote:
>> >> On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote:
>> >> > OK, you could not be more correct. I want GDB to handle it, not the FE.
>> >> > However, how do I let "GDB handle it", while using the 'set tty'
>> >> > command? I guess that's the question I've been asking all along.
>> >> 
>> >> Make it trap the SIGINT and do something sensible with it.
>> >
>> > OK, so, does anyone think this suggestion would have drawbacks?
>> > That is, modify GDB so that the FE can always send the signal to the GDB
>> > pty, and GDB will figure out what to do with the signal. This would be a
>> > wonderful solution. That way, if the FE is using 'set tty' or not, it
>> > could always send the signal to the same place.
>> 
>> I totally think you should be using 'set tty'.  It's the only way to
>> keep inferior and GDB output straight, and nobody has ever had the
>> forbearance to explain the drawbacks to me.
>> 
>> I still think it's odd that you would actually want a way to send a
>> SIGINT to either the inferior if running or GDB otherwise.  But if you
>> really do want that, then making GDB deal with it seems like the right
>> thing.
>
> Jim, the user can do this exact sort of thing just using plain old GDB. 
> They don't even know they are doing it probably, they just hit ^c. So, 
> it's not that I want to send ^c to GDB or inferior, I just want to do 
> what the user wants.
>
> OK, I have to assume you know more about this than I do. You've been
> doing it for much longer. Where does your FE send the ^c when GDB is
> running? when inferior is running?

I don't have an FE of my own.  I'm just working from my understanding
of how the design is supposed to support what you're trying to do.

I understand that the disposal of C-c in plain old GDB depends on
whether the inferior is running or not.  But is that a feature?  What
happens when the user hits C-c just as their program hits a
breakpoint?  Probably GDB will behave just fine, but if it had
undertaken something interruptible in response to the breakpoint, then
the reaction of the system to the user's keystroke --- a breakpoint
hit, and then the interruption of something the user hadn't expected
--- is pretty confusing.

As I've said, if I were implementing an FE, I would provide a command
to interrupt the inferior, implemented by sending a signal via the
pty, and I wouldn't provide a command to interrupt GDB; I'd try to
change the way I interacted with GDB to avoid long pauses, or display
progress bars, or something like that.

Re: invoking GDB from FE and signals

[Bob Rossi]

On Fri, May 19, 2006 at 10:17:02AM -0700, Jim Blandy wrote:
> 
> Bob Rossi <bob_rossi@cox.net> writes:
> > On Fri, May 19, 2006 at 08:49:19AM -0400, Daniel Jacobowitz wrote:
> >> On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote:
> >> > OK, you could not be more correct. I want GDB to handle it, not the FE.
> >> > However, how do I let "GDB handle it", while using the 'set tty'
> >> > command? I guess that's the question I've been asking all along.
> >> 
> >> Make it trap the SIGINT and do something sensible with it.
> >
> > OK, so, does anyone think this suggestion would have drawbacks?
> > That is, modify GDB so that the FE can always send the signal to the GDB
> > pty, and GDB will figure out what to do with the signal. This would be a
> > wonderful solution. That way, if the FE is using 'set tty' or not, it
> > could always send the signal to the same place.
> 
> I totally think you should be using 'set tty'.  It's the only way to
> keep inferior and GDB output straight, and nobody has ever had the
> forbearance to explain the drawbacks to me.
> 
> I still think it's odd that you would actually want a way to send a
> SIGINT to either the inferior if running or GDB otherwise.  But if you
> really do want that, then making GDB deal with it seems like the right
> thing.

Jim, the user can do this exact sort of thing just using plain old GDB. 
They don't even know they are doing it probably, they just hit ^c. So, 
it's not that I want to send ^c to GDB or inferior, I just want to do 
what the user wants.

OK, I have to assume you know more about this than I do. You've been
doing it for much longer. Where does your FE send the ^c when GDB is
running? when inferior is running?

Anyone maintaining an FE using the 'set tty', what does your FE do when
it get's a ^c under these 2 case's?

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
> On Fri, May 19, 2006 at 08:49:19AM -0400, Daniel Jacobowitz wrote:
>> On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote:
>> > OK, you could not be more correct. I want GDB to handle it, not the FE.
>> > However, how do I let "GDB handle it", while using the 'set tty'
>> > command? I guess that's the question I've been asking all along.
>> 
>> Make it trap the SIGINT and do something sensible with it.
>
> OK, so, does anyone think this suggestion would have drawbacks?
> That is, modify GDB so that the FE can always send the signal to the GDB
> pty, and GDB will figure out what to do with the signal. This would be a
> wonderful solution. That way, if the FE is using 'set tty' or not, it
> could always send the signal to the same place.

I totally think you should be using 'set tty'.  It's the only way to
keep inferior and GDB output straight, and nobody has ever had the
forbearance to explain the drawbacks to me.

I still think it's odd that you would actually want a way to send a
SIGINT to either the inferior if running or GDB otherwise.  But if you
really do want that, then making GDB deal with it seems like the right
thing.

Re: invoking GDB from FE and signals

[Bob Rossi]

On Fri, May 19, 2006 at 08:49:19AM -0400, Daniel Jacobowitz wrote:
> On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote:
> > OK, you could not be more correct. I want GDB to handle it, not the FE.
> > However, how do I let "GDB handle it", while using the 'set tty'
> > command? I guess that's the question I've been asking all along.
> 
> Make it trap the SIGINT and do something sensible with it.

OK, so, does anyone think this suggestion would have drawbacks?
That is, modify GDB so that the FE can always send the signal to the GDB
pty, and GDB will figure out what to do with the signal. This would be a
wonderful solution. That way, if the FE is using 'set tty' or not, it
could always send the signal to the same place.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote:
> OK, you could not be more correct. I want GDB to handle it, not the FE.
> However, how do I let "GDB handle it", while using the 'set tty'
> command? I guess that's the question I've been asking all along.

Make it trap the SIGINT and do something sensible with it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Thu, May 18, 2006 at 10:54:53PM -0400, Daniel Jacobowitz wrote:
> On Thu, May 18, 2006 at 08:58:31PM -0400, Bob Rossi wrote:
> > Unless I'm wrong, and I often am!, I think the 'set tty' option that GDB
> > provides has a major limitation. If the FE uses it, it can't determine
> > which pty to send the SIGINT to when it recieves one. With this in mind,
> > I suggest a new solution that could go in several directions.
> > 
> > The inferior and GDB should be run on the same pseudo terminal for the
> > reasons above. So moving the inferior to it's own terminal doesn't help
> > much. I suggest adding a new feature to GDB, something like 
> > 'set gdb_io_tty /dev/pts/1' which would tell GDB what tty to output it's
> > I/O. However, GDB wouldn't change it's pty. This way, signals will be
> > delivered as if GDB was on the same terminal. Daniel, correct me if I'm
> > wrong, but this solution would work with the changes we made to the test
> > suite also.
> 
> I think you're getting too caught up in the details of your current
> problem, and you've forgotten what you originally wanted to do.

Well, you could be correct. However, I need to both send a signal to the
pty, and know where to send it to. There kind of lumped together.

> You want to be able to interrupt the inferior, if it is running, and
> GDB, if it is not.  So why not make GDB handle that?  It's GDB's job to
> keep track anyway.

OK, you could not be more correct. I want GDB to handle it, not the FE.
However, how do I let "GDB handle it", while using the 'set tty'
command? I guess that's the question I've been asking all along.

There is 3 choices, and 1 of them is not possible for me, which leaves 2
choices. Does either of these allow GDB to just handle it?

- always send the ^c to GDB's pty
- always send the ^c to inferior's pty
- send the ^c to the active GDB or inferior. With 'set tty' this becomes
  a problem that doesn't exist otherwise.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Daniel Jacobowitz]

On Thu, May 18, 2006 at 08:58:31PM -0400, Bob Rossi wrote:
> Unless I'm wrong, and I often am!, I think the 'set tty' option that GDB
> provides has a major limitation. If the FE uses it, it can't determine
> which pty to send the SIGINT to when it recieves one. With this in mind,
> I suggest a new solution that could go in several directions.
> 
> The inferior and GDB should be run on the same pseudo terminal for the
> reasons above. So moving the inferior to it's own terminal doesn't help
> much. I suggest adding a new feature to GDB, something like 
> 'set gdb_io_tty /dev/pts/1' which would tell GDB what tty to output it's
> I/O. However, GDB wouldn't change it's pty. This way, signals will be
> delivered as if GDB was on the same terminal. Daniel, correct me if I'm
> wrong, but this solution would work with the changes we made to the test
> suite also.

I think you're getting too caught up in the details of your current
problem, and you've forgotten what you originally wanted to do.

You want to be able to interrupt the inferior, if it is running, and
GDB, if it is not.  So why not make GDB handle that?  It's GDB's job to
keep track anyway.

-- 
Daniel Jacobowitz
CodeSourcery

Re: invoking GDB from FE and signals

[Bob Rossi]

On Thu, May 18, 2006 at 10:44:48AM -0700, Jim Blandy wrote:
> 
> Bob Rossi <bob_rossi@cox.net> writes:
> >> > We send the signal to the inferior ... the problem when running gdb is to
> >> > ... get the inferior PID ... sigh. We have circumvent the problem is
> >> > commercial products but did not fine a generic way to get the pid.
> >> 
> >> You should use the 'set tty' command to run the user's program under
> >> its own pseudo-tty, and then stuff the appropriate control characters
> >> at the master side.  That's the only way to do the right thing if the
> >> inferior is doing job-control-like stuff, like a shell.
> >
> > OK, I agree with all of this, and Jim your comments have been extremly
> > helpful. I'm left confused on 2 issues.
> >
> > Do I ever want to send a ^c signal to GDB? That is, if the inferior is
> > not running, should I still send the ^c to the inferior's tty? If I'm
> > supposed to send the ^c to GDB when it is running and to the inferior
> > when it is running, then that is impossible from my point of view. And a
> > good argument against using the tty command.
> 
> I think you're coming at the problem in an odd way.  You seem to be
> thinking, "I've got this C-c --- what do I do with it?"  Instead,
> think about what facilities your user needs.

Well, I'm realising, this certainly wouldn't be an issue if I didn't use
the tty command. In fact, emacs doesn't use the tty command by default,
so it handles all of this perfectly I'd imagine. The only downside that
emacs has to deal with, is separating the gdb/mi output and the inferior
output. This is discussed below.

> - They need a way to stop their program and get control back to GDB.

Yes.

> - They may (or may not, it's not clear to me) need a way to interrupt
>   GDB when it's doing a long computation.

Yes. As long as GDB handles this nicely in regards to the MI output.
If the user can do this at the GDB console, the FE should support it,
no?

> There's a clear need for the first thing.  The user's program isn't
> behaving as expected; that's why they're debugging it.  So you need to
> provide some command to interrupt a running program.  This can be
> implemented by sending a SIGINT via the pty.

Understood. I think that the discusion on HOW to send a signal to a pty
has been answered very well. I do un

> The second thing, I'm not sure you need.  I mean, how many word
> processors provide a way to interrupt some long internal computation
> they're doing?  If you do find a case like this, well, your front end
> knows what it just asked GDB to do; when it sends some request that it
> thinks might take a long time and would like to allow the user to
> interrupt, it can tell the user interface about that and handle
> requests to bail by sending a SIGINT to the GDB process itself.  And
> make sure your parser is prepared for whatever kind of malformed stuff
> that produces (if it does; I don't know).

Assuming I want to handle both of those case's like emacs does, I'm left
with a problem because I use the 'set tty' command. For instance, I get
a ^c, I need to send it somewhere because I don't know if GDB is running
or if the inferior is running.

Unless I'm wrong, and I often am!, I think the 'set tty' option that GDB
provides has a major limitation. If the FE uses it, it can't determine
which pty to send the SIGINT to when it recieves one. With this in mind,
I suggest a new solution that could go in several directions.

The inferior and GDB should be run on the same pseudo terminal for the
reasons above. So moving the inferior to it's own terminal doesn't help
much. I suggest adding a new feature to GDB, something like 
'set gdb_io_tty /dev/pts/1' which would tell GDB what tty to output it's
I/O. However, GDB wouldn't change it's pty. This way, signals will be
delivered as if GDB was on the same terminal. Daniel, correct me if I'm
wrong, but this solution would work with the changes we made to the test
suite also.

Another approach would be to act like valgrind does. That is, provide a
file descriptor that GDB should write to. For instance, gdb
--file-io=100, which would cause GDB to output it's I/O on file
descriptor 100. This has a limitation in that it could possibly
interface with the inferior outputting data on file descriptor 100.
However, it would port to windows very nicely.

Any comments?

Anyways, thanks to everyone for helping me understand HOW to send a
signal to a pty. This information was more than helpful.

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Andreas Schwab]

Bob Rossi <bob_rossi@cox.net> writes:

> Is this the prefered way of sending a single to the inferior? I am only
> now realizing how many different case's that emacs supports.

The downside of sending the signal by yourself is that you cannot signal a
privileged process, whereas the terminal driver has no such restriction.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: invoking GDB from FE and signals

[Andreas Schwab]

Jim Blandy <jimb@codesourcery.com> writes:

> Andreas Schwab <schwab@suse.de> writes:
>> Bob Rossi <bob_rossi@cox.net> writes:
>>
>>> I find in emacs:process.c code that they send the SIGINT in different
>>> ways
>>>     /* If possible, send signals to the entire pgrp
>>>        by sending an input character to it.  */
>>>
>>>     /* TERMIOS is the latest and bestest, and seems most likely to
>>>        work.  If the system has it, use it.  */
>>>     case SIGINT:
>>>       sig_char = &t.c_cc[VINTR];
>>>       break;
>>>     ...
>>>     send_process (proc, sig_char, 1, Qnil);
>>
>> This part is only active if SIGNALS_VIA_CHARACTERS is defined.  That is
>> defined mostly for BSD-derived systems, but not, for example, for Linux.
>> The fallback is to send the signal to the foreground process group of the
>> terminal.
>
> Do you know why they prefer that approach on Linux?

According to s/gnu-linux.h:

/* Let's try this out, just in case.
   Nah.  Rik Faith <faith@cs.unc.edu> says it doesn't work well.  */
/* #define SIGNALS_VIA_CHARACTERS */

1993-06-09  Jim Blandy  (jimb@wookumz.gnu.ai.mit.edu)

	* s/linux.h (SIGNALS_VIA_CHARACTERS): Don't #define this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: invoking GDB from FE and signals

[Jim Blandy]

Andreas Schwab <schwab@suse.de> writes:
> Bob Rossi <bob_rossi@cox.net> writes:
>
>> I find in emacs:process.c code that they send the SIGINT in different
>> ways
>>     /* If possible, send signals to the entire pgrp
>>        by sending an input character to it.  */
>>
>>     /* TERMIOS is the latest and bestest, and seems most likely to
>>        work.  If the system has it, use it.  */
>>     case SIGINT:
>>       sig_char = &t.c_cc[VINTR];
>>       break;
>>     ...
>>     send_process (proc, sig_char, 1, Qnil);
>
> This part is only active if SIGNALS_VIA_CHARACTERS is defined.  That is
> defined mostly for BSD-derived systems, but not, for example, for Linux.
> The fallback is to send the signal to the foreground process group of the
> terminal.

Do you know why they prefer that approach on Linux?  There are race
conditions doing it either way, but the SIGNALS_VIA_CHARACTERS one
seems less likely:

- If SIGNALS_VIA_CHARACTERS is #defined, then we get the tty's "intr"
  character and send that.  The race is that the child could change
  its "intr" character between the time we fetch it and the time the
  tty processes the one we've sent.

- Otherwise, we get the tty's controlling process group with
  tcgetpgrp, and then use killpg to send that process group the signal
  we want.  The race is that the child could change its process group
  between the time we fetch it and the time we send it.

A shell changes the terminal's process group every time it runs a
command.

Re: invoking GDB from FE and signals

[Bob Rossi]

On Thu, May 18, 2006 at 11:49:01PM +0200, Andreas Schwab wrote:
> Bob Rossi <bob_rossi@cox.net> writes:
> 
> > I find in emacs:process.c code that they send the SIGINT in different
> > ways
> >     /* If possible, send signals to the entire pgrp
> >        by sending an input character to it.  */
> >
> >     /* TERMIOS is the latest and bestest, and seems most likely to
> >        work.  If the system has it, use it.  */
> >     case SIGINT:
> >       sig_char = &t.c_cc[VINTR];
> >       break;
> >     ...
> >     send_process (proc, sig_char, 1, Qnil);
> 
> This part is only active if SIGNALS_VIA_CHARACTERS is defined.  That is
> defined mostly for BSD-derived systems, but not, for example, for Linux.
> The fallback is to send the signal to the foreground process group of the
> terminal.

Thanks Andreas, I see now. The code is below on how to get the
foreground process group. I see that it get's the process group and then
calls killpg.

Is this the prefered way of sending a single to the inferior? I am only
now realizing how many different case's that emacs supports.

Thanks,
Bob Rossi

/* Return the foreground process group for the tty/pty that
   the process P uses.  */
static int
emacs_get_tty_pgrp (p)
     struct Lisp_Process *p;
{
  int gid = -1;

#ifdef TIOCGPGRP
  if (ioctl (XINT (p->infd), TIOCGPGRP, &gid) == -1 && ! NILP (p->tty_name))
    {
      int fd;
      /* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
         master side.  Try the slave side.  */
      fd = emacs_open (XSTRING (p->tty_name)->data, O_RDONLY, 0);

      if (fd != -1)
        {
          ioctl (fd, TIOCGPGRP, &gid);
          emacs_close (fd);
        }
    }
#endif /* defined (TIOCGPGRP ) */

  return gid;
}

Re: invoking GDB from FE and signals

[Andreas Schwab]

Bob Rossi <bob_rossi@cox.net> writes:

> I find in emacs:process.c code that they send the SIGINT in different
> ways
>     /* If possible, send signals to the entire pgrp
>        by sending an input character to it.  */
>
>     /* TERMIOS is the latest and bestest, and seems most likely to
>        work.  If the system has it, use it.  */
>     case SIGINT:
>       sig_char = &t.c_cc[VINTR];
>       break;
>     ...
>     send_process (proc, sig_char, 1, Qnil);

This part is only active if SIGNALS_VIA_CHARACTERS is defined.  That is
defined mostly for BSD-derived systems, but not, for example, for Linux.
The fallback is to send the signal to the foreground process group of the
terminal.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: invoking GDB from FE and signals

[Jim Blandy]

Bob Rossi <bob_rossi@cox.net> writes:
>> > We send the signal to the inferior ... the problem when running gdb is to
>> > ... get the inferior PID ... sigh. We have circumvent the problem is
>> > commercial products but did not fine a generic way to get the pid.
>> 
>> You should use the 'set tty' command to run the user's program under
>> its own pseudo-tty, and then stuff the appropriate control characters
>> at the master side.  That's the only way to do the right thing if the
>> inferior is doing job-control-like stuff, like a shell.
>
> OK, I agree with all of this, and Jim your comments have been extremly
> helpful. I'm left confused on 2 issues.
>
> Do I ever want to send a ^c signal to GDB? That is, if the inferior is
> not running, should I still send the ^c to the inferior's tty? If I'm
> supposed to send the ^c to GDB when it is running and to the inferior
> when it is running, then that is impossible from my point of view. And a
> good argument against using the tty command.

I think you're coming at the problem in an odd way.  You seem to be
thinking, "I've got this C-c --- what do I do with it?"  Instead,
think about what facilities your user needs.

- They need a way to stop their program and get control back to GDB.
- They may (or may not, it's not clear to me) need a way to interrupt
  GDB when it's doing a long computation.

There's a clear need for the first thing.  The user's program isn't
behaving as expected; that's why they're debugging it.  So you need to
provide some command to interrupt a running program.  This can be
implemented by sending a SIGINT via the pty.

The second thing, I'm not sure you need.  I mean, how many word
processors provide a way to interrupt some long internal computation
they're doing?  If you do find a case like this, well, your front end
knows what it just asked GDB to do; when it sends some request that it
thinks might take a long time and would like to allow the user to
interrupt, it can tell the user interface about that and handle
requests to bail by sending a SIGINT to the GDB process itself.  And
make sure your parser is prepared for whatever kind of malformed stuff
that produces (if it does; I don't know).

> The other confusion point for me is that there is a magic ioctl that
> will send a signal to the tty process group. After looking in emacs, I'm
> thinking that the confusion was that there is an ioctl to get the
> character that needs to be written via 'write' to the pty in order to
> have the pty generate the signal. Look at the code below, is it true
> that the FE should just call 'write' but with the appropriate character.
>
> I find in emacs:process.c code that they send the SIGINT in different
> ways
>     /* If possible, send signals to the entire pgrp
>        by sending an input character to it.  */
>
>     /* TERMIOS is the latest and bestest, and seems most likely to
>        work.  If the system has it, use it.  */
>     case SIGINT:
>       sig_char = &t.c_cc[VINTR];
>       break;
>     ...
>     send_process (proc, sig_char, 1, Qnil);
>
> which is simply getting the ^c char tha the terminal expects to send it
> or
>
>    /* On Berkeley descendants, the following IOCTL's retrieve the
>       current control characters.  */
>    case SIGINT:
>      ioctl (XINT (p->infd), TIOCGETC, &c);
>      send_process (proc, &c.t_intrc, 1, Qnil);
> or
>   /* On SYSV descendants, the TCGETA ioctl retrieves the current
>    * control characters.  */
>   case SIGINT:
>     ioctl (XINT (p->infd), TCGETA, &t);
>     send_process (proc, &t.c_cc[VINTR], 1, Qnil);
> or
>     case SIGINT:
>       send_process (proc, "\003", 1, Qnil);     /* ^C */
>       goto whoosh;

You're right.  I had been sure there was some way to just get the pty
to send the signal to its current process group directly, but this
seems to be the way it's done.

(My advice: just implement the TERMIOS case, and wait until people
complain before you worry about the other cases.  That Emacs code is
very old, and the termios interface is very widely available these
days.)

Re: invoking GDB from FE and signals

[Bob Rossi]

> > We send the signal to the inferior ... the problem when running gdb is to
> > ... get the inferior PID ... sigh. We have circumvent the problem is
> > commercial products but did not fine a generic way to get the pid.
> 
> You should use the 'set tty' command to run the user's program under
> its own pseudo-tty, and then stuff the appropriate control characters
> at the master side.  That's the only way to do the right thing if the
> inferior is doing job-control-like stuff, like a shell.

OK, I agree with all of this, and Jim your comments have been extremly
helpful. I'm left confused on 2 issues.

Do I ever want to send a ^c signal to GDB? That is, if the inferior is
not running, should I still send the ^c to the inferior's tty? If I'm
supposed to send the ^c to GDB when it is running and to the inferior
when it is running, then that is impossible from my point of view. And a
good argument against using the tty command.

The other confusion point for me is that there is a magic ioctl that
will send a signal to the tty process group. After looking in emacs, I'm
thinking that the confusion was that there is an ioctl to get the
character that needs to be written via 'write' to the pty in order to
have the pty generate the signal. Look at the code below, is it true
that the FE should just call 'write' but with the appropriate character.

I find in emacs:process.c code that they send the SIGINT in different
ways
    /* If possible, send signals to the entire pgrp
       by sending an input character to it.  */

    /* TERMIOS is the latest and bestest, and seems most likely to
       work.  If the system has it, use it.  */
    case SIGINT:
      sig_char = &t.c_cc[VINTR];
      break;
    ...
    send_process (proc, sig_char, 1, Qnil);

which is simply getting the ^c char tha the terminal expects to send it
or

   /* On Berkeley descendants, the following IOCTL's retrieve the
      current control characters.  */
   case SIGINT:
     ioctl (XINT (p->infd), TIOCGETC, &c);
     send_process (proc, &c.t_intrc, 1, Qnil);
or
  /* On SYSV descendants, the TCGETA ioctl retrieves the current
   * control characters.  */
  case SIGINT:
    ioctl (XINT (p->infd), TCGETA, &t);
    send_process (proc, &t.c_cc[VINTR], 1, Qnil);
or
    case SIGINT:
      send_process (proc, "\003", 1, Qnil);     /* ^C */
      goto whoosh;

Thanks,
Bob Rossi

Re: invoking GDB from FE and signals

[Andreas Schwab]

Alain Magloire <alain@qnx.com> writes:

> We send the signal to the inferior ... the problem when running gdb is to
> ... get the inferior PID ... sigh. We have circumvent the problem is
> commercial products but did not fine a generic way to get the pid.

If you send the signal to the terminal process group you should be fine.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: invoking GDB from FE and signals

[Bob Rossi]

On Thu, May 18, 2006 at 10:35:53AM -0400, Alain Magloire wrote:
> 
> 
> > Bob Rossi
> > Sent: Wednesday, May 17, 2006 9:41 PM
> > To: gdb@sources.redhat.com
> > Subject: Re: invoking GDB from FE and signals
> > 
> > On Sat, May 13, 2006 at 11:10:57AM -0400, Daniel Jacobowitz wrote:
> > > On Sat, May 13, 2006 at 11:10:26AM -0400, Bob Rossi wrote:
> > > > OK, I can find out the details. However, I'm thinking the supported
> > way
> > > > of starting GDB from a FE is via a pipe. This would prevent readline
> > > > from being in the way, and is the only way to do it with MI anyways,
> > > > right?
> > >
> > > There's no such thing as "the supported way".
> > 
> > There is something else I just discovered today. I think it's rather
> > important. If you start GDB via a pipe, then it will not ask you
> > questions like
> >   Make breakpoint pending on future shared library load? (y or [n])
> > or
> >   The program is running.  Exit anyway? (y or n)
> > instead, it will just assume the answer is yes.
> > 
> > So, switching to a pty has other advantages that might not seem obvious
> > at first. This could also be documented.
> > 
> 
> Surprisingly, the main reason why we use a pty in the Eclipse/CDT is to get
> rid of the xxxx number of PRs about not seeing the output of printf() and
> before you ask ... telling the user to fflush() and explaining the stdio
> flushing policy for pipes/files vs. terminal ended up in hate mails.

Wow. Alain, thanks for alerting me of this! This is a great point!
I've already decided that using a pty was the way to go, but now I'm
sure of it.

> We send the signal to the inferior ... the problem when running gdb is to
> ... get the inferior PID ... sigh. We have circumvent the problem is
> commercial products but did not fine a generic way to get the pid.

Yes, I'm thinking that there is now way to do what I would like as long
as I'm using the 'tty' command. I'm going to have to come up with an
alternative to using the 'tty' command.

Bob Rossi

RE: invoking GDB from FE and signals

[Alain Magloire]

> Bob Rossi
> Sent: Wednesday, May 17, 2006 9:41 PM
> To: gdb@sources.redhat.com
> Subject: Re: invoking GDB from FE and signals
> 
> On Sat, May 13, 2006 at 11:10:57AM -0400, Daniel Jacobowitz wrote:
> > On Sat, May 13, 2006 at 11:10:26AM -0400, Bob Rossi wrote:
> > > OK, I can find out the details. However, I'm thinking the supported
> way
> > > of starting GDB from a FE is via a pipe. This would prevent readline
> > > from being in the way, and is the only way to do it with MI anyways,
> > > right?
> >
> > There's no such thing as "the supported way".
> 
> There is something else I just discovered today. I think it's rather
> important. If you start GDB via a pipe, then it will not ask you
> questions like
>   Make breakpoint pending on future shared library load? (y or [n])
> or
>   The program is running.  Exit anyway? (y or n)
> instead, it will just assume the answer is yes.
> 
> So, switching to a pty has other advantages that might not seem obvious
> at first. This could also be documented.
> 

Surprisingly, the main reason why we use a pty in the Eclipse/CDT is to get
rid of the xxxx number of PRs about not seeing the output of printf() and
before you ask ... telling the user to fflush() and explaining the stdio
flushing policy for pipes/files vs. terminal ended up in hate mails.

We send the signal to the inferior ... the problem when running gdb is to
... get the inferior PID ... sigh. We have circumvent the problem is
commercial products but did not fine a generic way to get the pid.