From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11536 invoked by alias); 21 Mar 2007 21:09:26 -0000 Received: (qmail 11527 invoked by uid 22791); 21 Mar 2007 21:09:26 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Mar 2007 21:09:22 +0000 Received: from kahikatea.snap.net.nz (105.61.255.123.dynamic.snap.net.nz [123.255.61.105]) by viper.snap.net.nz (Postfix) with ESMTP id AB71D3DA187; Thu, 22 Mar 2007 09:09:18 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id BB9EE4F72E; Thu, 22 Mar 2007 09:09:17 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17921.40699.742164.983281@kahikatea.snap.net.nz> Date: Wed, 21 Mar 2007 21:09:00 -0000 To: Daniel Jacobowitz , Denis PILAT , gdb-patches Subject: Re: [RFC] -thread-info new command In-Reply-To: <17919.21588.93918.661753@kahikatea.snap.net.nz> References: <45FE9E6A.3030906@st.com> <17919.15500.439138.600411@kahikatea.snap.net.nz> <17919.20575.286260.761826@kahikatea.snap.net.nz> <20070320031409.GA7336@caradoc.them.org> <17919.21588.93918.661753@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.95.6 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: 2007-03/txt/msg00190.txt.bz2 > but I could only come up with: > > http://sourceware.org/ml/gdb-patches/2006-11/msg00208.html > > which didn't seem that simple and is probably not correct I've gone through the archives to try to understand the changes. The above message says: Well we need to propagate the error message back to captured_mi_execute_command. Actually there are currently two ways to catch an error in MI: 1) Using error () and catch_exception. 2) Using MI_CMD_ERROR and mi_error_message. The first gets caught in mi_execute_command and the error message is stored in result.message. The second goes back to captured_mi_execute_command and the error message is manually stored in mi_error_message. I think that only one method should be used and this should be the first one. It appears that catch_exceptions_with_msg was used to avoid using error_last_message () but this was no longer needed when mi_execute_command was changed to use catch_exception instead of catch_exceptions (the comment "Can this use of catch_exceptions..." is an anachronism). The error message should be available in result.message for these functions (gdb_thread_select, gdb_breakpoint,..) anyway. -- Nick http://www.inet.net.nz/~nickrob