[Mono-devel-list] IKVM show stopper
jeroen at sumatra.nl
Fri Jun 11 02:41:24 EDT 2004
Paolo Molaro wrote:
> On 06/10/04 Jeroen Frijters wrote:
> > To fix an IKVM bug, I had to make a change to how MethodBuilder
> > instances are converted into their baked MethodInfo
> equivalents. This
> > exposed a bug in Mono's (0.95) ModuleBuilder.GetMethodToken().
> > The attached program demonstrates that
> > allocates a new token, instead of returning the existing
> one, when it is
> > called with a MethodInfo (instead of a MethodBuilder).
> > I think the bug is in mono_image_create_token
> (reflection.c), as that
> > just blindly assigns a new token value when the passed in
> object is a
> > MonoMethod.
> I fixed this for methods and ctors in cvs. Do you need it for
> fields as well as all the other tokens?
Thanks! At the moment methods and ctors are all I need, but I think I'll
need fields as well in the future (once I fix my field reflection code),
but this isn't as critical because field names are rarely overloaded. I
don't need any other tokens though.
> > Also, if you look at the generated test.dll, you'll see
> that the actual
> > method token is also one off from the one reported by
> > MethodBuilder.GetToken().
> Yes. Do you rely on that behaviour?
No. It was just something I noticed. My understanding is that they are
supposed to match, but I certainly don't need it.
> (it's easier since we keep separate arrays for ctors and
> normal methods).
> In the general case the tokens won't match, because the methods of a
> type need to be contiguous in the PE file, but with reflection you can
> create a few mthods for a type, then for another, then for the old one
> again and the tokesn are assigned sequentially.
I don't know anything about the PE format, so this might be a lame
suggestion, but can't you simply write them out in token order when the
assembly is saved?
More information about the Mono-devel-list