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