From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20064 invoked by alias); 14 Jun 2013 17:40:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20052 invoked by uid 89); 14 Jun 2013 17:40:38 -0000 X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 14 Jun 2013 17:40:37 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5EHea3e025471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Jun 2013 13:40:36 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5EHeY9h027287; Fri, 14 Jun 2013 13:40:35 -0400 Message-ID: <51BB5592.9060502@redhat.com> Date: Fri, 14 Jun 2013 17:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sergio Durigan Junior CC: GDB Patches Subject: Re: [RFC/PATCH] Add new internal variable $_signo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00338.txt.bz2 On 06/14/2013 01:37 AM, Sergio Durigan Junior wrote: > The signal can obviously be recovered because GDB itself mentioned it > when saying that it was "signal 11, Segmentation fault", and this is why > this patch came to life. It basically sets/creates a new internal > variable called "$_signo" to be used as an alternative to > $_siginfo.si_signo when this one is unavailable. It's not a complex > patch per se, but I would certainly like some review because there may > be other places where we should set the variable as well. $_siginfo always prints the siginfo of the selected thread. If you change threads, you'll print the newly selected thread's siginfo. >From the way $_signo described in terms of $_siginfo, and is implemented in the core target, it should always print the signal of the last event of the selected thread. However, the implementation for live targets is doing something else: On 06/14/2013 01:37 AM, Sergio Durigan Junior wrote: > - print_signal_exited_reason (ecs->ws.value.sig); > + { > + print_signal_exited_reason (ecs->ws.value.sig); > + /* Set the value of the internal variable $_signo to hold the > + signal number received by the inferior. */ > + set_internalvar_integer (lookup_internalvar ("_signo"), > + (LONGEST) ecs->ws.value.sig); > + } This bit is actually implementing a counterpart of the existing $_exitcode. At this point the inferior is gone already, and $_siginfo couldn't ever work, even if the backend supports it. This case is actually a different scenario from $_siginfo. I think it'd make more sense to call this one $_exitsignal, as sibling of the existing $_exitcode. $_exitcode records the inferior's exit code for normal exits, $_exitsignal would record the signal number for signal exits. Like $_exitcode, $_exitsignal should print the same signal number until the inferior exits again, no matter which thread you're looking at. Looked like that, $_exitsignal just seems like an obvious omission. Since when debugging a core file you're seeing a snapshot of the inferior _before_ it exited, I think pedantically it makes more sense for corelow to _not_ set $_exitsignal. However, should still be able to get the info from the $_signo of the thread that exited (the one that gets selected when you load the core). So in sum, here are my suggestions: Add $_signo, but make it print the signal of the last event the thread received. I'd add a last_status field in struct thread_info to record that info. Don't implement $_signo as a regular integer convenience variable that gets set whenever a thread reports an event. That won't work correctly in non-stop mode, where you can be looking at thread #1, while other threads could be hitting events (but the user remains with thread #1 selected). See how the $_thread variable is implemented as lazy convenience, very similar to what you need. If you're willing and I think it'd be a nice addition too, add $_exitsignal, and make it print the uncaught signal that made the process die. Document it with something like: @item $_exitcode @vindex $_exitcode@r{, convenience variable} The variable @code{$_exitcode} is automatically set to the exit code when -the program being debugged terminates. +the program being debugged terminates normally. + +@item $_exitsignal +@vindex $_exitsignal@r{, convenience variable} +The variable @code{$_exitsignal} is automatically set to the +signal number when the program being debugged dies due to an +uncaught signal. I suggest making $_signo and $_exitsignal separate patches, even. BTW, IMO, $_exitcode (and $_exitsignal) should print the exit code/signal of the selected inferior. It was never adjusted for multi-inferior, so it always prints the exit code of the inferior that happened to exit last. Simon's patch for displaying the inferior's exit-code in MI's -list-thread-groups records the info in the inferior struct. Once that is in, we'd just need to make $_exitcode a lazy convenience var too. > The patch also contains a testcase and an update to the documentation in > order to mention the new convenience variable. The patch adds code to handle signalled live inferiors, but the test didn't exercise that. > +@item $_signo > +@vindex $_signo@r{, convenience variable} > +The variable @code{$_signo} contains the signal number received by the > +inferior. > +Its purpose is to serve as an auxiliary way of retrieving > +such information for when the kernel does not provide the necessary > +support for @code{$_siginfo} to be used. IMO, this whole sentence would be better reduced to: "Unlike $_siginfo below, $_signo is always available in all supported targets." $_signo should work on Windows, for example, where there's no concept of $_siginfo. > Note that @code{$_signo} > +could be @code{void} (empty), if the application has not received any > +signals. For example, it will be @code{void} before you execute the > +@code{run} command. -- Pedro Alves