Re: invoking GDB from FE and signals

[Jim Blandy <jimb@codesourcery.com>]

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.