ImagePointer

[Andrew Johnson <an...@uk.ibm.com>]

I'm reiterating a  concern about ImagePointer with mixed 32-bit and 64-bit 
processes in an address space.

Kato has the concept of multiple processes per address space, and this 
actually occurs with z/OS and _BPX_SHAREAS=YES

The ImageProcess has a getPointerSize method, but how would 
ImagePointer.getPointerAt work in the situation of a 32-bit process and a 
64-bit process in the same address space? One implementation couldn't work 
for both.

One idea is to have an extra ImagePointer.getPointerAt(long offset, int 
pointerSize) method. This could work, though a default pointer size may 
need to be given for an address space. If the processes had different 
endianness then there would be further problems with getLongAt etc.

Perhaps it is better if ImagePointers are internally typed, or exist as 
different subclasses. An appropriate ImagePointer is then returned from 
Kato for reading data. Normally getPointerAt, getLongAt work as expected. 
With mixed word size or endianness in an address space the appropriate 
ImagePointer is returned which knows about the process mode. This could 
even extend to ImageStackFrame.getBasePointer returning different 
ImagePointers for mixed 32-bit and 64-bit frames in the same process. This 
means that users of Kato should be encouraged to use ImagePointer.add() to 
build new ImagePointers while retaining the type information. 
ImageAddressSpace.getPointer would only return default ImagePointers for 
the address space.

This might be useful for shared virtual address space operating systems. 
These could be modelled in Kato as one address space, but the pointers 
obtained from a process would know about access restrictions for that 
process so that the appropriate MemoryAccessException could be thrown when 
required.

On a more general note, in September I reviewed the Final version of First 
Early Draft Review document and marked up a paper copy with my extensive 
comments. I gave this copy to Steve Poole. I hope that soon everyone will 
be able to see my comments.

Andrew Johnson
(personal view)





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: ImagePointer

[Steve Poole <sp...@googlemail.com>]

On Mon, Dec 7, 2009 at 9:09 AM, Andrew Johnson <an...@uk.ibm.com>wrote:

> I'm reiterating a  concern about ImagePointer with mixed 32-bit and 64-bit
> processes in an address space.
>
> Kato has the concept of multiple processes per address space, and this
> actually occurs with z/OS and _BPX_SHAREAS=YES
>
> The ImageProcess has a getPointerSize method, but how would
> ImagePointer.getPointerAt work in the situation of a 32-bit process and a
> 64-bit process in the same address space? One implementation couldn't work
> for both.
>
> One idea is to have an extra ImagePointer.getPointerAt(long offset, int
> pointerSize) method. This could work, though a default pointer size may
> need to be given for an address space. If the processes had different
> endianness then there would be further problems with getLongAt etc.
>
> Perhaps it is better if ImagePointers are internally typed, or exist as
> different subclasses. An appropriate ImagePointer is then returned from
> Kato for reading data. Normally getPointerAt, getLongAt work as expected.
> With mixed word size or endianness in an address space the appropriate
> ImagePointer is returned which knows about the process mode. This could
> even extend to ImageStackFrame.getBasePointer returning different
> ImagePointers for mixed 32-bit and 64-bit frames in the same process. This
> means that users of Kato should be encouraged to use ImagePointer.add() to
> build new ImagePointers while retaining the type information.
> ImageAddressSpace.getPointer would only return default ImagePointers for
> the address space.
>
> This might be useful for shared virtual address space operating systems.
> These could be modelled in Kato as one address space, but the pointers
> obtained from a process would know about access restrictions for that
> process so that the appropriate MemoryAccessException could be thrown when
> required.
>
> Yep - that makes sense.  The default should be that the ImagePointer
created by getPointerAt would be  sized according to the parent pointer
characteristics - which itself is defined by some other container - such as
ImageAddressSpace, ImageSection etc.

It sounds like we should consider being able to create an ImagePointer from
an ImageProcess and have a getPointerAt method on that.

 On a more general note, in September I reviewed the Final version of First
> Early Draft Review document and marked up a paper copy with my extensive
> comments. I gave this copy to Steve Poole. I hope that soon everyone will
> be able to see my comments.
>
> Andrew Johnson
> (personal view)
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>


-- 
Steve