From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5930 invoked by alias); 27 Oct 2003 15:39:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5921 invoked from network); 27 Oct 2003 15:39:02 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 27 Oct 2003 15:39:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 467072B89; Mon, 27 Oct 2003 10:39:02 -0500 (EST) Message-ID: <3F9D3C16.2070205@redhat.com> Date: Mon, 27 Oct 2003 15:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [rfc] New files "memory.[hc]" References: <3F99901B.6030005@redhat.com> <1031024210419.ZM3102@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00780.txt.bz2 > On Oct 24, 4:48pm, Andrew Cagney wrote: > > >> What do people think of putting the new (with target parameter) methods, >> that wrap target_{read,write} in a new file "memory.[hc]"? I think they >> are going to end up cluttering up "target.[hc]". > > > Sounds okay to me. But is it a good idea, as in will it make the code easier to read, find, and understand? The old target-memory routines are all "hidden" (well i think they are :-) in gdbcore.h and corefile.c > Do you have a naming scheme in mind for the new methods? This is the comment I added to "target.h": /* Wrappers to target read/write that perform memory transfers. They throw an error if the memory transfer fails. NOTE: cagney/2003-10-23: The naming schema is lifted from "frame.h". The parameter order is lifted from get_frame_memory, which in turn lifted it from read_memory. */ and this is the corresponding comment in "frame.h": /* The following is the intended naming schema for frame functions. It isn't 100% consistent, but it is aproaching that. Frame naming schema: Prefixes: get_frame_WHAT...(): Get WHAT from the THIS frame (functionaly equivalent to THIS->next->unwind->what) frame_unwind_WHAT...(): Unwind THIS frame's WHAT from the NEXT frame. put_frame_WHAT...(): Put a value into this frame (unsafe, need to invalidate the frame / regcache afterwards) (better name more strongly hinting at its unsafeness) safe_....(): Safer version of various functions, doesn't throw an error (leave this for later?). Returns non-zero if the fetch succeeds. Return a freshly allocated error message? Suffixes: void /frame/_WHAT(): Read WHAT's value into the buffer parameter. ULONGEST /frame/_WHAT_unsigned(): Return an unsigned value (the alternative is *frame_unsigned_WHAT). LONGEST /frame/_WHAT_signed(): Return WHAT signed value. What: /frame/_memory* (frame, coreaddr, len [, buf]): Extract/return *memory. /frame/_register* (frame, regnum [, buf]): extract/return register. CORE_ADDR /frame/_{pc,sp,...} (frame): Resume address, innner most stack *address, ... */ which gave rise to: extern void get_target_memory (struct target_ops *ops, CORE_ADDR addr, void *buf, LONGEST len); extern ULONGEST get_target_memory_unsigned (struct target_ops *ops, CORE_ADDR addr, int len); Andrew