This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix Linux attach to signalled/stopped processes
On Fri, Apr 11, 2008 at 11:00:37PM +0100, Pedro Alves wrote:
> ?> + ?/* Pass on the last signal, if appropriate. ?*/
> > + ?if (lp->status == 0 && GET_LWP (lp->ptid) == GET_LWP (inferior_ptid)
> > + ? ? ?&& stop_signal != TARGET_SIGNAL_0 && signal_pass_state (stop_signal))
> > + ? ?lp->status = W_STOPCODE (target_signal_to_host (stop_signal));
>
> You're writing to lp->status of inferior_ptid, which isn't garantied
> to be the main thread or the thread that got the last signal (user
> may have used the "thread" command to switch threads, or we're stopped
> at a breakpoint in some other thread not the main one, for example, or
> the kernel decided to send the signal to some other thread because the
> main one was already stopped?).
I want the ptid associated with the global variable stop_signal. It's
deliberately not the ptid of the main thread but I hadn't thought
about the thread command. Any idea how to do this? Is that variable
context-switched (or should it be)?
> >- ?iterate_over_lwps (detach_callback, NULL);
> >+ ?iterate_over_lwps (detach_callback, &status);
> >
>
> Passing &status seems bogus, since you're passing the status
> in lp->status ?
Stray from the previous version. Removed, thanks.
> I don't see where you're actually sending the signal. Even if you
> did, it isn't guarantied you are passing this signal. It will miss it
> if inferior_ptid isn't the main thread. See comments above.
>
> Also, why the alloca dance instead of using
> "Sending signal %d to %s\n" directly, if you're not doing anything
> else with args? AKA, what's the plan for args?
These two are related - it goes to inf_ptrace_detach just outside the
range of the context diff.
> What's supposed to happen if stop_signal was a SIGTRAP ?
Then it shouldn't have signal_pass_state set.
--
Daniel Jacobowitz
CodeSourcery