Re: SIGINT & signal handler vs Linux kernel...

[paawan oza <paawan1982 at yahoo dot com>]

Hi,

Actually this topic I tried to bring in, little long back.
then I asked next question.
gdb internally send SIGINT to stop and then get it back.
and then sends SIGSTOP to send every thread in linux_nat_wait I suppose.

now one thing was in my mind was why dont we send SIGSTOP intially to stop the process ?
and of course we configure signals..as follows

handle SIGSTOP nopass. (to avoid recursion I think).

will not it work this way ?

Regards,
Oza.




--- On Fri, 8/14/09, Joel Brobecker <brobecker@adacore.com> wrote:

> From: Joel Brobecker <brobecker@adacore.com>
> Subject: SIGINT & signal handler vs Linux kernel...
> To: gdb@sourceware.org
> Date: Friday, August 14, 2009, 1:17 AM
> Hello,
> 
> We just noticed something really odd: When debugging a
> threaded program
> that has a SIGINT handler, pressing ctrl-c no longer
> interrupts that
> program (we attached the debugger to the process, not sure
> if this
> does make a difference or not). Instead, the program simply
> executes
> the signal handler.
> 
> I found the following entry in our bug database:
> http://sourceware.org/bugzilla/show_bug.cgi?id=9425
> 
> As well as a reference to that discussion with Roland:
> http://bugzilla.kernel.org/show_bug.cgi?id=9039
> 
> I just wanted to see if anyone knew what the current status
> was?
> It sounds from the discussion above that an enhancement in
> the kernel
> is necessary first, and then a corresponding change in GDB
> can be made
> to get the SIGINT notifications. Would that be correct?
> (the kernel
> enhancement hasn't been done, right?) If the kernel
> enhancement has
> been done, I could have a look at the GDB part, but I have
> never looked
> at Linux and wouldn't be able to help with that part...
> 
> Thanks,
> -- 
> Joel
>