From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5985 invoked by alias); 13 Oct 2010 07:14:14 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 5975 invoked by uid 22791); 13 Oct 2010 07:14:12 -0000 X-SWARE-Spam-Status: No, hits=-4.6 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 Friday, 10 September 2010 21:07:25 +0200 <20100910190725.GC27699@redhat.com> References: <20100903224047.GA8917@redhat.com> <20100906182359.GB22839@redhat.com> <20100906194229.GA27405@redhat.com> <20100906205927.GA30471@redhat.com> <20100910100948.C0254405D5@magilla.sf.frob.com> <20100910190725.GC27699@redhat.com> Message-Id: <20101013071359.A789A401B2@magilla.sf.frob.com> Date: Wed, 13 Oct 2010 07:14:00 -0000 X-SW-Source: 2010-q4/txt/msg00013.txt.bz2 > But. Suppose we have to attached engines. The first engine gets > UTRACE_SIGNAL_REPORT and returns "UTRACE_STOP | UTRACE_SIGNAL_IGN". Right, that's what it would do. I see, you're saying that the report.result passed on to the next engine would appear like it had been a real signal that the previous engine decided to ignore (or whose sa_handler==SIG_IGN or default action was to ignore). Hmm. Well, it's also distinguished by having orig_ka==NULL in the callback. Any real signal has a non-null orig_ka argument. > or yes, it returns UTRACE_SIGNAL_DELIVER after gdb does "signal XX". > > Now. The second engine gets UTRACE_SIGNAL_DELIVER or UTRACE_SIGNAL_IGN, > not UTRACE_SIGNAL_REPORT. At least in the UTRACE_SIGNAL_DELIVER case, that's really the true thing for it to see. The previous engine decided to do a signal delivery (as directed by return_ka), so the next engine needs to see this to know what the prevailing state of play is now. > That is why ugdb_signal_report(UTRACE_SIGNAL_REPORT) tries to return > UTRACE_STOP | utrace_signal_action(action) to not change report->result > (passed to the next tracee) inside the reporting loop. Well, it *can* do that. If UTRACE_SIGNAL_REPORT (or anything else random) is the ultimate report.result from the whole callback loop, we treat it just like UTRACE_SIGNAL_IGN. > The worst case is UTRACE_SIGNAL_HANDLER. Single-stepping should know > about this case. This means that any engine should always return > UTRACE_resume_action | UTRACE_SIGNAL_HANDLER. I see. This is indeed the only way for any engine to know that it's getting the UTRACE_SIGNAL_HANDLER specific notification rather than some random fallout of someone else's UTRACE_REPORT request or whatnot. > > > 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. > > If ->report_signal(orig_ka) was calles with orig_ka == NULL, then, > whatever utrace_signal_action(action) we see, originally it was > either UTRACE_SIGNAL_HANDLER or UTRACE_SIGNAL_REPORT but another engine > returned, say, UTRACE_SIGNAL_DELIVER/UTRACE_SIGNAL_IGN to deliver/stop. Right. But this is in fact just the same for either UTRACE_SIGNAL_REPORT or UTRACE_SIGNAL_HANDLER. > > > 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. > > Yes, agreed. But there is one corner case. Until we generalize > utrace_stop()->ptrace_notify_stop() hook, the tracee can be reported as > stopped to gdb, but before it actually stops it can recieve a signal. I don't follow this. If we're stopping, then we don't "receive" (dequeue) any other signal until we get resumed. That should be fine from gdb's point of view. The next signal is just pending for later. The signal that we just reported was a) in fact reported to gdb and b) is still sitting in the siginfo_t on stack and the engine can examine/modify that before letting the thread resume. (The kerneldoc paragraph about @report_signal in utrace.h makes this guarantee.) Thanks, Roland