From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20038 invoked by alias); 10 Jan 2010 14:00:52 -0000 Received: (qmail 20026 invoked by uid 22791); 10 Jan 2010 14:00:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Jan 2010 14:00:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 614F22BAB79; Sun, 10 Jan 2010 09:00:44 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AvXVQfp+qZtM; Sun, 10 Jan 2010 09:00:44 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 286852BAB71; Sun, 10 Jan 2010 09:00:43 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id B7311F5976; Sun, 10 Jan 2010 18:00:29 +0400 (RET) Date: Sun, 10 Jan 2010 14:00:00 -0000 From: Joel Brobecker To: Hui Zhu Cc: Stan Shebs , Tom Tromey , Stan Shebs , Michael Snyder , gdb-patches ml , Eli Zaretskii Subject: Re: [RFC] Let "gcore" command accept a suffix argument Message-ID: <20100110140029.GF2007@adacore.com> References: <4B3BEDCC.9040103@earthlink.net> <20100106075757.GF24777@adacore.com> <20100109105557.GA2007@adacore.com> <20100110054328.GD2007@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-01/txt/msg00224.txt.bz2 > But I think we have know the type of the val that we want output, the > string we want it as string, the number we want it to be number. > Are you sure we need point out the type of val to be output? > > And this idea is out of my ability. Sorry about it. If you could have a look at how the "printf" command is implemented, you might be surprised as to how easy this task might be. For someone who tackled the really complex project of grafting process record onto GDB, I sincerely think that this should nearly be a no-brainer for you: 1. Extract out the entire contents of the printf_command implementation into a separate function. Let's call it ui_printf: void ui_printf (char *args, ui_file *stream) 2. Adjust the body so that all the printf/puts, etc, basically anything printing on stdout, are replace by equivalent calls that print in the given ui_file *stream; 3. Implement the body of printf_command by simply calling this new function with gdb_stdout as the ui_file; printf_command (char *args, int from_tty) { ui_printf (args, gdb_stout); } 4. Implement the eval function roughly like so: eval_command (char *args, int from_tty) { struct ui_file *ui_out = mem_fileopen (); char *expanded; struct cleanup *old_chain; ui_printf (args, ui_out); // That's the new function extracted // from printf_command, which prints // in a ui_file instead of stdout. expanded = ui_file_xstrdup (ui_out, NULL); old_chain = make_cleanup (xfree, expanded); execute_command (expanded, from_tty); do_cleanups (old_chain); } -- Joel