[rfc] New files "memory.[hc]"

[rfc] New files "memory.[hc]"

[Andrew Cagney]

Hello,

At present the old (non target parameterized) memory functions all live 
in gdbcore.h, and corefile.c (I guess "core" is "core" in the 
traditional sense :-).

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]".

Andrew

Re: [rfc] New files "memory.[hc]"

[Kevin Buettner]

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.

Do you have a naming scheme in mind for the new methods?

Kevin

Re: [rfc] New files "memory.[hc]"

[Andrew Cagney]

> 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

Re: [rfc] New files "memory.[hc]"

[Kevin Buettner]

On Oct 27, 10:39am, Andrew Cagney wrote:

> > 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

I know it's kind of long, but how about "target-memory.[hc]" ?

Kevin

Re: [rfc] New files "memory.[hc]"

[Andrew Cagney]

>> 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
> 
> 
> I know it's kind of long, but how about "target-memory.[hc]" ?

I think its a bit too long (right on the edge of 8.3).

Andrew