Re: [RFA] gdbserver/lynx178: spurious SIG61 signal when resuming inferior.

[Joel Brobecker <brobecker@adacore.com>]

> Old lynx-nat.c did:
> 
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/Attic/lynx-nat.c?rev=1.23&content-type=text/x-cvsweb-markup&cvsroot=src
> 
>   /* If pid == -1, then we want to step/continue all threads, else
>      we only want to step/continue a single thread.  */
>   if (pid == -1)
>     {
>       pid = PIDGET (inferior_ptid);
>       func = step ? PTRACE_SINGLESTEP : PTRACE_CONT;
>     }
>   else
>     func = step ? PTRACE_SINGLESTEP_ONE : PTRACE_CONT_ONE;
> 
> 
> I'd like to believe that just doing that in gdbserver too
> would fix the scheduler-locking example.  :-)

I just tried that, and I am not sure yet how well this is going to
work. It'll at least require a change in the "wait" routine which
resumes the execution after a "new-thread" event, because do not want
to resume the execution using the thread's ptid, because we'd switch
to a PTRACE_CONT_ONE request. I tried to see if I could make it work
quickly, but got inconclusive results (process hanging), so I am
leaving that for another day :-).

> For the SIG61 issue, I wonder whether for PTRACE_CONT,
> it's "continue main pid process" that we should always use
> instead of "last reported thread id" (and that's what the old
> lynx-nat.c did too).  Did you try that?

Yes, I did that a while ago. Looking at the man page for
PTRACE_CONT:

        This request is always directed to an individual
        thread specified by pid, while all the threads in
        the traced process are also to be resumed.

The man page also says a bit earlier:

        Per-thread, but effective on the entire process.

Based on the above, I think that using the currently "active"
thread (the thread that caused the process to stop) helps
avoid having the debugger influence the program's behavior
by influencing its scheduling.

Nevertheless, I tried that again today, and that is not sufficient
to prevent the SIG61 signal from being raised.

So I think that the patch as I proposed it still makes sense.
I know you pre-approved it, but I want to make sure that I answered
all your questions properly before going ahead with the commit.

> Sorry to be picky.  IMO, it's good to have all these
> experimentation results archived, for when somebody proposes
> removing/changing the "make sure to resume last reported" code
> at some point...

Not at all, I think this makes sense.

-- 
Joel