This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 follows

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

will not it work this way ?


--- On Fri, 8/14/09, Joel Brobecker <> wrote:

> From: Joel Brobecker <>
> Subject: SIGINT & signal handler vs Linux kernel...
> To:
> 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:
> As well as a reference to that discussion with Roland:
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]