From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10955 invoked by alias); 4 Apr 2007 14:36:42 -0000 Received: (qmail 10943 invoked by uid 22791); 4 Apr 2007 14:36:42 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Apr 2007 15:36:33 +0100 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-03.spheriq.net with ESMTP id l34EaUXY030683 for ; Wed, 4 Apr 2007 14:36:30 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id l34EaTLJ006989 for ; Wed, 4 Apr 2007 14:36:30 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id l34EaRsa003860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2007 14:36:29 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id ADADEDA46; Wed, 4 Apr 2007 14:36:22 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4AD734751B; Wed, 4 Apr 2007 14:36:22 +0000 (GMT) Received: from [164.129.44.95] (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.7.5a-GA) with ESMTP id CKD89204 (AUTH "denis pilat"); Wed, 4 Apr 2007 16:36:21 +0200 (CEST) Message-ID: <4613B7E5.6080309@st.com> Date: Wed, 04 Apr 2007 14:36:00 -0000 From: Denis PILAT User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Nick Roberts Cc: Daniel Jacobowitz , gdb-patches Subject: Re: [RFC] -thread-info new command 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> <17929.36288.344474.485310@farnswood.snap.net.nz> In-Reply-To: <17929.36288.344474.485310@farnswood.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-04/txt/msg00018.txt.bz2 Nick Roberts wrote: > > > 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."? > > Is there anything new about that ? Should I re-propose a patch for -thread-info ? -- Denis