From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18818 invoked by alias); 27 Mar 2007 21:36:45 -0000 Received: (qmail 18809 invoked by uid 22791); 27 Mar 2007 21:36:45 -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; Tue, 27 Mar 2007 22:36:40 +0100 Received: from farnswood.snap.net.nz (74.61.255.123.dynamic.snap.net.nz [123.255.61.74]) by viper.snap.net.nz (Postfix) with ESMTP id B840A3D909F; Wed, 28 Mar 2007 09:36:36 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 5798B627ED; Tue, 27 Mar 2007 22:33:53 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17929.36288.344474.485310@farnswood.snap.net.nz> Date: Tue, 27 Mar 2007 21:36:00 -0000 To: Daniel Jacobowitz Cc: Denis PILAT , gdb-patches Subject: Re: [RFC] -thread-info new command In-Reply-To: <20070327195414.GN28164@caradoc.them.org> 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> <17921.40699.742164.983281@kahikatea.snap.net.nz> <20070327195414.GN28164@caradoc.them.org> X-Mailer: VM 7.19 under Emacs 22.0.96.1 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/msg00282.txt.bz2 > > 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. > > Once upon a time there were supposed to be more things using "libgdb" > - these gdb_* wrapper functions. It didn't come to pass. I thought the gdb_* wrapper function were just designed to catch exceptions. Does your statement defeat the logic of my suggestion? > For now can we do the minimal fix for this problem? I apologize I was > never clear enough about what I meant when I said that, so here's a > patch. Yes. I can't believe now that I didn't consider this option. > ... > 2007-03-27 Daniel Jacobowitz > > * breakpoint.c (gdb_breakpoint_query): Really return an > enum gdb_rc. > (gdb_breakpoint): Likewise. > * thread.c (do_captured_list_thread_ids): Likewise. > (do_captured_thread_select): Likewise. > * mi/mi-main.c (mi_cmd_thread_select): Expect an enum gdb_rc. > (mi_cmd_thread_list_ids): Remove bogus initialization. I think that the do_captured_* functions should have return type enum gdb_rc not int. More generally though, re my patch, does make_cleaunp work on deprecated_set_gdb_event_hooks? Do you think it's a good idea to distinguish between user errors, e.g, "No stack." and front end errors, e.g, "-var-delete: Usage: [-c] EXPRESSION."? -- Nick http://www.inet.net.nz/~nickrob