This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: invoking GDB from FE and signals
Alain Magloire <alain@qnx.com> writes:
>> 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.
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.