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

Joel Brobecker
2013-05-16T12:24:56Z

> 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