incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: ImagePointer
Date Tue, 08 Dec 2009 09:24:35 GMT
On Mon, Dec 7, 2009 at 9:09 AM, Andrew Johnson <andrew_johnson@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message