Jan Kotas wrote:
>
> Get/SetILFunctionBody apparently worked well in the Rotor Beta releases, but it got
> broken in the final Rotor release with the problem you have described.
>
> A quick patch for the problem is to apply the following modifications to
> PEFile::RVAToPointer in sscli\clr\src\vm\pefile.cpp (the 3 new lines are marked with
> ***):
>
> BYTE *PEFile::RVAToPointer(DWORD rva)
> {
> if (rva == 0)
> return NULL;
>
> if(m_hCorModule) {
> DWORD types = CorMap::ImageType(m_hCorModule);
> if(types == CorLoadOSMap || types == CorLoadDataMap || types ==
> CorLoadOSImage)
> {
> *** DWORD t = rva;
> rva = Cor_RtlImageRvaToOffset(m_pNT, rva, GetUnmappedFileLength());
> *** if (rva == 0)
> *** rva = t;
> }
> }
>
> return m_base + rva;
> }
>
> This is just a workaround for the problem that can cause undesired behavior under
> some
> circumstances. The clean fix would involve more complex changes in several files - I
> can put it
> together if there is interest in it.
Thanks for your detailed reply, Jan. Your patch would work.
I've also implemented another workaround, which a bit more involved
where I use a flag bit in MethodDesc to indicate if its body has been
changed, and change GetILHeader to return base + (unresolved) rva if
that the case. This doesn't work for someone calling GetILCode directly
with an rva obtained from metadata. And perhaps it suffers from similar
undesired behaviors as your patch?
In any case, I'd like to have a proper fix for the problem.
>
> -Jan
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
Thanks,
Nam
> -----Original Message-----
> From: Nam Tran [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 13, 2003 4:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET-ROTOR] Problems with profiling
>
> I'm using the Rotor release of 01 Nov 2002. That's the final release,
> correct?
>
> The problem with replacing the method body is exactly as Fabian
> described, i.e. the module has image type CorLoadOSMap, CorLoadOSImage,
> or CorLoadDataMap, resulting in BAD_FORMAT_ASSERT(header.Code != 0).
>
> Note that with the sample "read-only" profiler, some event masks
> cause havoc, too.
>
> It'd be great if someone who has successfully used SetILFunctionBody
> in Rotor tells us of their experience.
>
> Nam
>
> Jan Kotas wrote:
> >
> > We have done a lot of bug fixes for the final release. I remember some
> of those had to do with CorLoadOSMap, CorLoadOSImage. Try to download
> the final release and reproduce the problem with it.
> >
> > We haven't done a lot of comprehensive testing of profiling interfaces
> in Rotor, so there may be bugs. But I have heard people are able to
> successfully use SetILFunctionBody in Rotor.
> >
> > -Jan
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > -----Original Message-----
> > From: Schmied Fabian [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, February 13, 2003 1:44 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [DOTNET-ROTOR] Problems with profiling
> >
> > Nam,
> >
> > I had the same problem: Allocating a method body with the allocator
> yielded a memory block which did not fit into the file sections
> specified in the module headers. Unfortunately, I could not solve the
> problem, so if anybody out there knows what the problem is here, please
> tell us.
> >
> > Fabian
> >
> > PS: The problem in my case is the following (speaking of CLR 1.0 and
> SSCLI 1.0, release 2):
> > The memory allocated using the IMethodMalloc has of course an RVA
> which is not part of any of the module's sections, as the are specified
> in the module's file header.
> >
> > However, if a module has the image type CorLoadOSMap, CorLoadOSImage,
> or CorLoadDataMap (whose meaning I don't know at all),
> PEFile::RVAToPointer delegates to Cor_RtlImageRvaToOffset, which finally
> results in calling Cor_RtlImageRvaToSection32. This iterates through the
> PEFile's sections, looking where the RVA fits in and calculating the
> code pointer accordingly.
> >
> > Since the RVA doesn't fit in any of the sections, it returns 0, the
> code pointer is wrongly calculated and a BAD_FORMAT_ASSERT(header.Code
> != 0) fires. However, different than in your case, I found that it
> didn't work with the CLR either (which threw a BadFormatException, I
> think). Only if the image type of the module was CorLoadImageMap, or if
> I manually skipped Cor_RtlImageRvaToOffset using the debugger, it would
> run correctly.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Nam Tran [mailto:[EMAIL PROTECTED]
> > Gesendet: Do 13.02.2003 04:10
> > An: [EMAIL PROTECTED]
> > Cc:
> > Betreff: [DOTNET-ROTOR] Problems with profiling
> >
> >
> >
> > I've run into problems with Rotor's profiling interface while
> trying
> > some simple things, initially just replacing body of a tiny
> method
> > with an exact copy. I base my code on the sample profiler. I
> try the
> > same thing with the CLR and things work fine there. Here are
> the
> > problems:
> >
> > - Some event mask combinations cause problem in Rotor (with
> just
> > the straight sample profiler, none of my changes yet)
> > + DN_PROFILER_MASK=0x20 causes a
> System.StackOverflowException
> > somewhere in closing down the EE
> > + DN_PROFILER_MASK=0x4f/0x8f cause an assertion failure at
> line
> > 401 in binder.cpp while the EE is trying to run some class
> > finalisation
> > + 0x40 and 0x80 work ok, I haven't tried others
> >
> > - With my changes to replace the body of a tiny method with an
> > exact copy as so:
> > In JITComplicationStarted, if it's ok to block the EE,
> > GetILFunctionBody
> > If it's tiny
> > GetILFunctionBodyAllocator
> > Allocate buffer with given size
> > Copy body to new buffer
> > SetILFunctionBody
> > Done.
> >
> > + This change works fine for the CLR
> >
> > + In Rotor, the new body is never picked up while the new
> RVA
> > is properly set for both the metadata and the in memory
> > MethodDesc*. Tracing it in the debugger, I found that the
> new
> > RVA, being after the module, is out of range when checked
> > against the values in the file headers. This result in
> > Module::GetILCode(rva) returning the base of the file.
> Part of
> > stack trace:
> > sscoree.dll!Cor_RtlImageRvaToSection32(...) Line 78
> > sscoree.dll!Cor_RtlImageRvaToSection(...) Line 110
> > sscoree.dll!Cor_RtlImageRvaToOffset(...) Line 203
> > sscoree.dll!PEFile::RVAToPointer(...) Line 110
> > sscoree.dll!Module::ResolveILRVA(...) Line 540
> > sscoree.dll!Module::GetILCode(...) Line 1760
> > The module (after replacing a method's body) is not
> 'InMemory',
> > I haven't come across the path where the module is an
> > InMemoryModule yet.
> >
> > Can anyone tell what I'm doing wrong and/or what else is
> wrong?
> >
> > Thanks,
> > Nam
> >
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
