From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25955 invoked by alias); 10 Sep 2010 10:10:01 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 25932 invoked by uid 22791); 10 Sep 2010 10:10:00 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov X-Fcc: ~/Mail/utrace Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v8 && ptrace In-Reply-To: Oleg Nesterov's message of Monday, 6 September 2010 22:59:27 +0200 <20100906205927.GA30471@redhat.com> References: <20100903224047.GA8917@redhat.com> <20100906182359.GB22839@redhat.com> <20100906194229.GA27405@redhat.com> <20100906205927.GA30471@redhat.com> Message-Id: <20100910100948.C0254405D5@magilla.sf.frob.com> Date: Fri, 10 Sep 2010 10:10:00 -0000 X-SW-Source: 2010-q3/txt/msg00173.txt.bz2 > I am a bit confused... OK, ugdb is wrong wrt multitracing. > UTRACE_SIGNAL_REPORT case shouldn't return "UTRACE_STOP | UTRACE_SIGNAL_IGN", > it should return "UTRACE_STOP | UTRACE_SIGNAL_REPORT" to keep report->result. No, UTRACE_SIGNAL_REPORT is not meant for a return value. Its only use is in the incoming argument to tell you that a given report_signal call is standing in for a report_quiesce(0) call. > But it needs to return UTRACE_SIGNAL_DELIVER? That's what you return when you want the signal delivered. When you are stopping the tracee to decide about the signal, that's not what you want. UTRACE_STOP | UTRACE_SIGNAL_IGN is correct to not deliver the signal right now, and stop instead. If you want to deliver the signal later, then you'll resume with UTRACE_INTERRUPT to ensure you get back to report_signal and that can fill in the details and return UTRACE_SIGNAL_DELIVER. > Probably we can check orig_ka != NULL and treat orig_ka == NULL as > UTRACE_SIGNAL_REPORT. Hopefully this can't be confused with > UTRACE_SIGNAL_HANDLER. I'm not really sure what you mean here. > Not sure about UTRACE_SIGNAL_HOLD, but this is very unlikely race. You probably don't want to use that, but I'm not entirely sure. ptrace doesn't use it, and the signal interception model is pretty much the same. Thanks, Roland