This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] gdbserver/lynx178: spurious SIG61 signal when resuming inferior.
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 May 2013 16:24:43 +0400
- Subject: Re: [RFA] gdbserver/lynx178: spurious SIG61 signal when resuming inferior.
- References: <1368441986-14478-1-git-send-email-brobecker at adacore dot com> <5190CCF9 dot 3020004 at redhat dot com> <20130513132802 dot GA32222 at adacore dot com> <5190F869 dot 3090408 at redhat dot 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