[Mono-dev] RVA Irregularities

[BGB]

[accidentally originally sent as a personal email, but may have group 
relavence...]


interesting...

so, when loading, are internal RVAs fixed up to their new addresses?
or is it the case that they are loaded to the new addresses, but the
metadata continues using the original RVAs?...


another mystery:
I will guess that Mono uses a different calling convention for JIT'ed code
than the native calling convention(s) on whatever target arch?...
if so, where can I look for info on this?

or, does it go and properly implement and use the CC for each arch, and map
the same code to each different CC?...


and, unrelated (a personal project, disregard if uninterested):

does it come off as a horrible hack to, on x86-64, not bother to internally
use the SysV calling convention (feeling the convention is just too painful
to implement with my approach to compiler writing and existing codebase),
and instead use a highly modified version of cdecl, and then leave it up to
the linker to generate any glue code needed to interface this with the
outside world?...

I eventually just decided on doing this in my compiler, but it still seems
like a horrible hack, and it seems like I am about the only person who does
not like SysV (or, for that matter, currently does not make use of SSA...).

my guess is that for people who use SSA, the convention is much easier to
target?...


but, yes, it is the sad fact that my existing working compilers, operate,
linearly... and do not mix so well with codegen issues that don't work
linearly, such as requiring non-trivial code reorganization or "elaborate"
register allocation (my reg allocator, again, works linearly, and typically
grabs "whatever register is free", whereas to direct the output of an
expression to a specific register requires operating in reverse, or walking
a tree...).

the convention would also not mix with nested function calls in my IL, and
it is also not sufficient to just pop the values back off into particular
registers (although, this would probably work for the Win64 convention,
since the rule in this case is fast and simple, and it is not possible to
have some args on the stack with later args in regs, ... as can happen with
SysV...).

but, yes, maybe my compiler is just a horrid piece of crap (I have one that
actually works, but the code is horrible IMO... so yeah, I know how easy it
is to end up with some not-easily-defeated piece of monstrosity code...),
but oh well...

I have some newer approaches that would give a more flexible compiler
(unwinding the internal stack machine to a graph layout and working on
this), but have never got around to finishing them (it is a slow
process...). this code would also make use of a more proper design (AKA: it
is divided into discrete and functionally independent modules, ...), but it
seems almost like compiler writing is a task naturally opposed to a clean
design...

actually, originally the whole middle-end of the compiler, was considered a
single big module... but it does too much to be a single module, and at the
same time, can't be easily subdivided (my last attempt at this produced
several components that were intended to be the base of a new compiler core,
but this part proved to be, elusive...).

I had just decided, "well, oh well, I have my existing older P-O-S compiler
for x86, may as well just use some hacks and make it work for x86-64 as
well..." (vs the new core, which is perpetually incomplete...).

oh well...


----- Original Message ----- 
From: "Kornél Pál" <kornelpal at gmail.com>
To: "Nathan McCauley" <nathan.mccauley at gmail.com>
Cc: <Mono-devel-list at lists.ximian.com>
Sent: Wednesday, January 07, 2009 9:04 AM
Subject: Re: [Mono-dev] RVA Irregularities


Hi,

I don't know how ProcessModule.BaseAddress is implemented on Linux but
you shouldn't use this.

If you want to look at the IL code open the file using FileStream or use
Cecil.

Note that even if you modify IL code that would not affect code that is
already compiled to native code.

Also note that RVA's are not required to be preserved when the image is
loaded to memory.

Mono on Windows is using LoadLibrary in most cases that will map the
image according to the RVAs but Linux has no support for PE files so
images are just loaded without mapping PE sections to their designated
virtual addresses.

Kornél