From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30788 invoked by alias); 6 Sep 2010 21:02:44 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 30779 invoked by uid 22791); 6 Sep 2010 21:02:44 -0000 X-SWARE-Spam-Status: No, hits=-6.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 Date: Mon, 06 Sep 2010 21:02:00 -0000 From: Oleg Nesterov To: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v8 && ptrace Message-ID: <20100906205927.GA30471@redhat.com> References: <20100903224047.GA8917@redhat.com> <20100906182359.GB22839@redhat.com> <20100906194229.GA27405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100906194229.GA27405@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00154.txt.bz2 On 09/06, Oleg Nesterov wrote: > > OK, I am stupid. Indeed, say, "return UTRACE_STOP | UTRACE_SIGNAL_IGN" > from under "case UTRACE_SIGNAL_REPORT" changes utrace_report->result, > and confuses other tracers. > > Probably we can ignore ptrace, but this also means ugdb conflicts > with itself and should be fixed. Yes. 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. But it needs to 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. Not sure about UTRACE_SIGNAL_HOLD, but this is very unlikely race. I need to re-read utrace_get_signal() with a fresh head. Oleg.