From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8058 invoked by alias); 27 Apr 2011 18:26:45 -0000 Received: (qmail 8044 invoked by uid 22791); 27 Apr 2011 18:26:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Apr 2011 18:26:30 +0000 Received: (qmail 25296 invoked from network); 27 Apr 2011 18:26:30 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Apr 2011 18:26:30 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: RFA: fix PR mi/12661 Date: Wed, 27 Apr 2011 18:26:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Tom Tromey References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104271926.30493.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg00522.txt.bz2 On Wednesday 27 April 2011 19:08:25, Tom Tromey wrote: > @@ -364,10 +364,16 @@ static void > mi_inferior_exit (struct inferior *inf) > { > struct mi_interp *mi = top_level_interpreter_data (); > + LONGEST exit_code; > + struct target_waitstatus status; > + ptid_t ptidp; > > target_terminal_ours (); > - fprintf_unfiltered (mi->event_channel, "thread-group-exited,id=\"i%d\"", > - inf->num); > + get_last_target_status (&ptidp, &status); > + exit_code = status.value.integer; > + fprintf_unfiltered (mi->event_channel, > + "thread-group-exited,id=\"i%d\",exit-code=\"%s\"", > + inf->num, int_string (exit_code, 8, 0, 0, 1)); > gdb_flush (mi->event_channel); > } 1 - I think this observer is called at places where get_last_target_status will not make sense --- the last status may well be of another inferior. E.g., debug against a live target, let it hit a break, detach. Then in the same gdb, open and close a core. 2 - this observer is called at places where the last target status wasn't an exit event, thus status.value.integer will not be an exit code. (e.g., infrun.c:follow_exec). -- Pedro Alves