From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27840 invoked by alias); 29 Nov 2009 02:24:29 -0000 Received: (qmail 27826 invoked by uid 22791); 29 Nov 2009 02:24:28 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Nov 2009 02:24:24 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 41B774407F for ; Sat, 28 Nov 2009 18:24:23 -0800 (PST) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 35E4FCD905 for ; Sat, 28 Nov 2009 18:24:23 -0800 (PST) Message-ID: <4B11DA3C.3000203@vmware.com> Date: Mon, 30 Nov 2009 13:39:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: gdb@sourceware.org Subject: [RFC] Let "gcore" command accept a suffix argument Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00213.txt.bz2 I can't find the reference message, but I have a recollection about somebody asking why some gdb command (may have been 'gcore') couldn't accept a gdb internal variable so that the filename could in effect be "computed", or disambiguated, to avoid overwriting. Having just done this for "record save", I thought I'd float the idea of generalizing it. 1) So -- what if 'gcore' were to accept an optional second argument which, if present, would be treated as an integer and suffixed to the gcore filename? So for instance: (gdb) set $a = 0 (gdb) gcore foo $a++ (gdb) step (gdb) gcore foo $a++ (gdb) step (gdb) gcore foo $a++ would result in three files: foo.0, foo.1, and foo.2. 2) Similarly, what if we were to do the same thing with add_setshow_filename_cmd, which is used for commands such as "set logging filename". Then a series of logging files could be created, each with a unique filename. Yes, I know, we could do the same thing with Python, but I'm not convinced that that is an argument against doing it stand alone (maybe for users who don't want to learn python). I'm prepared to submit a patch for 1 and 2, separately or together.