[Mono-devel-list] [PATCH] Opcode decomposition
bmaurer at users.sourceforge.net
Tue Apr 6 18:35:31 EDT 2004
Ok, the attached patch should deal with all the issues, except one
On Tue, 2004-04-06 at 07:28, Paolo Molaro wrote:
> No, it's perfectly correct there: read the spec about managed pointers.
> It's your code which is incorrect. When it's used to implement STRLEN
> it's fine, since the length is stored in managed memory. When you use it
> to access fields in unmanaged structures it's no longer correct.
Ok, so when doing this, I did the following:
> + if (source->type == STACK_MP || source->type == STACK_OBJ) \
> + load_source->type = STACK_MP; \
> + else if (source->type == STACK_PTR) \
> + load_source->type = STACK_PTR; \
> + else \
> + g_assert_not_reached (); \
However, I found the LDIND_I creates a STACK_MP. So, it seems like if I
were coding this using unsafe code in C#, I would still get a STACK_PTR
on the stack.
Luckily, according to the spec:
> In order to allow managed pointers to be used more flexibly, they are
> also permitted to point to areas that aren’t under the control of the
> CLI garbage collector, such as the evaluation stack, static variables,
> and unmanaged memory. This allows them to be used in many of the same
> ways that unmanaged pointers (U) are used.
Thus, this should be fine. Nonetheless, if there is actually a STACK_PTR
on the stack, I do *NOT* create a managed pointer from it, which seems
to be the reasonable behavior.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7971 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040406/736684c4/attachment.bin
More information about the Mono-devel-list