.NET assemblies and DLL rebasing

问题:

According to this article rebasing is not necessary for .NET assemblies due to JIT compilation of the code. The article states:

"JIT-compiled code does not have a rebasing problem since the addresses are generated at run time based on where the code is placed in memory. Also, MSIL is rarely affected by base address misses since MSIL references are token-based, rather than address-based. Thus when the JIT compiler is used, the system is resilient to base address collisions."

However, I have noticed that VS2008 assigns the default 0x0400000 base address to all assemblies (project properties > build > advanced) and if I do a listdlls /r for my process all my .NET assemblies are in fact rebased per default.

If I assign addresses myself, no rebasing is done.

My question is: What is rebased in this case and why?

EDIT: I should add that I am not talking about NGen'ed assemblies.

回答1:

CLR Loading mechanism uses LoadLibrary behind the scenes, so this is what you observe: 2 assemblies can't be loaded at the same address. Now what people often mean when they try to rebase a dll is to avoid the perf. hit of fix-ups, e.g. absolute addresses & function calls need to be "relocated" with the loaded base-address. CLR does not have this problem (not sure about static data in the application, which is the second part of those fix-ups, I would need to read up on this), because MSIL code is loaded on-demand when you call a function in the managed code. The MSIL then gets jitted and placed on the heap, a different one from normal object heap I believe, in the same manner CLR allocates and lays out new objects in your application.

回答2:

What OS are you running? I know that the vista and beyond introduced ASLR which randomizes the address space it loads dlls into. This happens for system dlls but not sure about .net - maybe something to look into.