[patch] Fix Linux attach to signalled/stopped processes

[Daniel Jacobowitz]

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