invoking GDB from FE and signals

> Bob Rossi
> Sent: Wednesday, May 17, 2006 9:41 PM
> To: gdbsources.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.

On Thu, May 18, 2006 at 10:35:53AM -0400, Alain Magloire
wrote:
> 
> 
> > Bob Rossi
> > Sent: Wednesday, May 17, 2006 9:41 PM
> > To: gdbsources.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

Alain Magloire <alainqnx.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, schwabsuse.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."

Alain Magloire <alainqnx.com> writes:
>> Bob Rossi
>> Sent: Wednesday, May 17, 2006 9:41 PM
>> To: gdbsources.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.

Well, I can sympathize with that, though.  The user would
like their
program to behave as if it were running under a tty.

> 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.

> > 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

Bob Rossi <bob_rossicox.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.)

Bob Rossi <bob_rossicox.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, schwabsuse.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."

On Thu, May 18, 2006 at 11:49:01PM +0200, Andreas Schwab
wrote:
> Bob Rossi <bob_rossicox.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;
}

Andreas Schwab <schwabsuse.de> writes:
> Bob Rossi <bob_rossicox.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.

Jim Blandy <jimbcodesourcery.com> writes:

> Andreas Schwab <schwabsuse.de> writes:
>> Bob Rossi <bob_rossicox.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 <faithcs.unc.edu> says it
doesn't work well.  */
/* #define SIGNALS_VIA_CHARACTERS */

1993-06-09  Jim Blandy  (jimbwookumz.gnu.ai.mit.edu)

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

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwabsuse.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."