[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pnet-developers] Re: back to Emit problems
From: |
Michal Moskal |
Subject: |
Re: [Pnet-developers] Re: back to Emit problems |
Date: |
Fri, 30 Apr 2004 11:52:24 +0200 |
User-agent: |
Mutt/1.4.2.1i |
On Fri, Apr 30, 2004 at 09:18:07AM +0200, Jonas Printzen wrote:
>
> >I believe there are no guarantees about validity of code generated by
> >S.R.E. It is even possible to insert some junky opcodes by accident
> >by using wrong overload of Emit method (like Emit(Ldarg_s,
> >0xdeadf00ddeadf00dULL)). Neither Mono nor MS .NET catches this kind of
> >error during generation. And verification is far more complex then just
> >valid opcodes.
>
> Hmm... pretty interresting. That would imply that with
> current Emit implementations one major argument for managed code
> is down the drain? If there is a way to actually execute junk...
Managed code != S.R.E. Under Windows one need to have reflection
permission to actually generate and run code. And that ,,major
argument'' is that one can verify code before running it -- you can
generate assembly and the verify it.
S.R.E. is low level API. Plain and simple.
> But on the other hand, the argument probably gets truncated by the
> next Emit() or EndScope().
Nope. When using Emit(Ldarg_S, ((int)1)) you will easly see that
ldarg.s 1
nop
nop
nop
is generated. Opcode for nop is 0. Figure out the rest.
> After all, isn't the ILGenerator and
> others hiding the 'program pointer'?
Emit() call simply puts bytes into method body.
--
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?