From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27262 invoked by alias); 18 Feb 2008 21:45:27 -0000 Received: (qmail 27253 invoked by uid 22791); 18 Feb 2008 21:45:27 -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; Mon, 18 Feb 2008 21:44:52 +0000 Received: from kahikatea.snap.net.nz (74.31.255.123.static.snap.net.nz [123.255.31.74]) by viper.snap.net.nz (Postfix) with ESMTP id 2015A3DA63F; Tue, 19 Feb 2008 10:44:45 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id CDA238FC6D; Tue, 19 Feb 2008 10:44:37 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18361.64577.771676.184618@kahikatea.snap.net.nz> Date: Mon, 18 Feb 2008 21:45:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Implement -thread-info. In-Reply-To: <200802181038.04497.vladimir@codesourcery.com> References: <200802171833.26673.vladimir@codesourcery.com> <18361.9433.599580.415136@kahikatea.snap.net.nz> <200802181038.04497.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.90.3 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: 2008-02/txt/msg00308.txt.bz2 > > mi_info_threads is nearly the same function as thread_command. > > You probably meant info_threads_command? Yes. > > Can this be > > used in a dual way just as -break-list uses breakpoint_1? > > I don't know -- I actually have no idea what magic makes breakpoint_1 to > work both for MI and CLI. Do you happen to know? It just seems to be a kind of overloading where the output format of functions like ui_out_field_string depends on the interpreter used (value of uiout). In cases where only one interpreter outputs anything ui_out_is_mi_like_p is used. > > Also Denis Pilat has already proposed a patch for -thread-info: > > http://sourceware.org/ml/gdb-patches/2007-03/msg00167.html > > I did not notice that. > > > > > How does your patch compare? (assuming the problem of return type is solved > > as has been done for thread_select). > > It appears that my patch: > > 1. Does not bother with making non-throwing function, as MI top-level can > handle exceptions. > > 2. Allows to print information about all threads. I see. Denis also proposed something for -thread-list-all-threads (http://sourceware.org/ml/gdb-patches/2007-03/msg00144.html) Do you not want to print the frame level? Also do you want to catch errors in print_stack_frame? Rather than: + print_stack_frame (get_selected_frame (NULL), 0, LOCATION); Would it be better to use: + print_frame_info (get_selected_frame (NULL), 1, LOC_AND_ADDRESS, 0); ? Note that with MI (following the thread with Denis) that the address gets printed anyway when print_stack_frame is used: args.print_what = ui_out_is_mi_like_p (uiout) ? LOC_AND_ADDRESS : print_what; > I don't know what problem of return type you refer to -- can you clarify? That, in Denis' patch, gdb_thread_info returns type enum gdb_rc but catch_exceptions_with_msg returns type int. (just like gdb_breakpoint and break_command_really did for a while). -- Nick http://www.inet.net.nz/~nickrob