This is the mail archive of the
mailing list for the GDB project.
Re: SIGINT & signal handler vs Linux kernel...
- From: paawan oza <paawan1982 at yahoo dot com>
- To: gdb at sourceware dot org, Joel Brobecker <brobecker at adacore dot com>
- Date: Fri, 14 Aug 2009 10:24:42 -0700 (PDT)
- Subject: Re: SIGINT & signal handler vs Linux kernel...
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 ?
--- On Fri, 8/14/09, Joel Brobecker <email@example.com> wrote:
> From: Joel Brobecker <firstname.lastname@example.org>
> Subject: SIGINT & signal handler vs Linux kernel...
> To: email@example.com
> Date: Friday, August 14, 2009, 1:17 AM
> 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
> the signal handler.
> I found the following entry in our bug database:
> As well as a reference to that discussion with Roland:
> I just wanted to see if anyone knew what the current status
> 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...