dereferencing pointers from frysk.value

dereferencing pointers from frysk.value

[Stan Cox]

Currently a class is essentially a list of types and a ByteBuffer of the
class contents.  It might be nice to dereference a pointer if the
pointer's type is char* and display the string.  However ClassType just
has a pointer, no task to do a task.getMemory() on.  DebugInfo has that
information.  Any suggestions on a nice way to handle this?

Re: dereferencing pointers from frysk.value

[Andrew Cagney]

So at present a "pointer" value is seen as a pair:
    type: pointer->char
    location: byte-buffer with size==sizeof(void*) and 
contents=="pointer value"
and there's nothing for the "pointer" to point into?

It sounds like the Type.toPrint() method should be parameterised with 
not just the ByteBuffer containing the value, but also the address space 
or segment[s] to which that value could refer.   As an aside, the 
toPrint method should probably also be parameterized with a base-type 
formatter so that <<print astruct -format x>> gives <<{ 0x123, 0x456 }>>

with these, PrintValue is reduced to:

    BaseTypeWriter baseTypeWriter = select writer based on -format
    Value result = cli.parseValue(expression);
    result.toPrint(outputWriter, task.getMemory(), baseTypeWriter)

Andrew

For the case of memory,
Stan Cox wrote:
> Currently a class is essentially a list of types and a ByteBuffer of the
> class contents.  It might be nice to dereference a pointer if the
> pointer's type is char* and display the string.  However ClassType just
> has a pointer, no task to do a task.getMemory() on.  DebugInfo has that
> information.  Any suggestions on a nice way to handle this?
>
>
>   

Re: dereferencing pointers from frysk.value

[Stan Cox]

On Fri, 2007-07-27 at 11:53 -0400, Andrew Cagney wrote:
> So at present a "pointer" value is seen as a pair:
>     type: pointer->char
>     location: byte-buffer with size==sizeof(void*) and 
> contents=="pointer value"
> and there's nothing for the "pointer" to point into?

Right.  Pointer operators are special cased so pointer class members
were the primary culprits.  Good idea to parameterize printing with the
buffer.  Now char* pointers get expanded similar to gdb (the formatting
is a little rough around the edges):
(fhpd) what mb
extern Type at <unknown>
(fhpd) what Type (inherits from Base1 and Base2)
{{byte * msg;void Base1 (byte * ) ;void ~Base1 () ;} Base1;{byte *
msg;void Base2 (byte * ) ;void ~Base2 () ;} Base2;byte * note;void Type
(byte * ,byte * ,byte * ) ;void ~Type () ;}
at /home/scox/accu/src/tstctors0.cc#33
(fhpd) print mb
{Base1={msg=0x401240 "static",Base1,~Base1},Base2={msg=0x40123b
"main",Base2,~Base2},note=0x401238 "mb",Type,~Type}

By the way here is an early template example (very rough formatting):

(fhpd) what xyz               
Derived at /home/scox/accu/src/tstctors0.cc#79
(fhpd) what Derived
{{void * * _vptr.Base3;void Base3 () ;void Base3 () ;char do_this
(char ) ;short int do_this (short int ) ;int do_this (int ) ;float
do_this (float ) ;} Base3;void Derived () ;void Derived () ;char do_this
(char ) ;short int do_this (short int ) ;int do_this (int ) ;float
do_this (float ) ;char do_this_impl<char> (char ) ;short int
do_this_impl<short int> (short int ) ;int do_this_impl<int>
(int ) ;float do_this_impl<float> (float ) ;}
at /home/scox/accu/src/tstctors0.cc#57
(fhpd) print xyz    
void*
{Base3={_vptr.Base3=0x401290,Base3,Base3,do_this,do_this,do_this,do_this},Derived,Derived,do_this,do_this,do_this,do_this,do_this_impl<char>,do_this_impl<short int>,do_this_impl<int>,do_this_impl<float>}