From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3058 invoked by alias); 8 Feb 2002 21:55:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2975 invoked from network); 8 Feb 2002 21:55:01 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Feb 2002 21:55:01 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E433E3E77; Fri, 8 Feb 2002 16:54:57 -0500 (EST) Message-ID: <3C644931.6050401@cygnus.com> Date: Fri, 08 Feb 2002 13:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Cc: "Frank Ch. Eigler" Subject: Re: A copy/save command ... References: <3C341E2D.6050009@cygnus.com> <3C476C0B.90009@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00148.txt.bz2 > cagney wrote: > > >> [...] >> The next was a more explicit save / unload / ... Michael's added >> ``generate-core-file'' following following on from that my next guess >> is to change that command to: >> (gdb) generate core-file >> and then also add things like: >> (gdb) generate >> for instance: >> (gdb) generate binary afile
... >> [...] > > > That looks good. (Please consider "dump" or "emit" or "unload" or > "save" (yes, asking the tracepoint save function to be renamed) or > something instead of "generate" as the verb though.) Renameing ``save-tracepoints'' is possible using the deprecate command mechanism. But perhaphs ``save'' should be reserved for GDB things. ``unload'' reminds me too much of shared libraries. But close to that is ``upload'' as suggested in the earlier thread the other is ``dump''. I show both below: upload value dump value write the TARGET value of as a sequence of bytes. upload memory dump memory write memory from to +-1 as bytes. While: (*(char*)START)@LENGTH is equvalent this would be more efficient. upload core dump core Hmm, the latter parses well. With the option: /a append to file (assuming I can get it to work and where applicable :-). As for creating files in different formats objcopy can be used but that certainly doesn't preclude extra options being added. Example: shell rm goo upload value/a goo (uint32) 0xdeadbeef upload value/a goo (uint8) 2 upload value/a goo (uint8) 3 would write: BE: de ad be ef 02 03 LE: ef be ad de 02 03 to a file. thoughts? Andrew