[Mono-devel-list] [PATCH] Move of Interlocked.Increment/Decrement/Exchange I4 to op codes

[Paolo Molaro]

BTW: please don't send me _three_ copies of the same mail.
Just post to the list.

On 11/29/04 Ben Maurer wrote:
> > for some examples of the problem. The emitted code has many
> > dependencies on the runtime internals and those need to be tracked
> > somehow. This has nothing to do with changes to corlib, which are
> > already handled. The offsets of course are only part of the issue,
> > there are many other dependencies on algorithms etc.
> 
> Every time you make install, corlib will be built along with the
> runtime, (even if the code was unchanged in corlib), so the aot will be
> invalidated.

Luckily the build system is not retarded: it doesn't build anything on
make install. You'll also note, if you try, that corlib is not rebuilt
if, for example, mini is changed. So your assumption is wrong.
The issue is whether to make the check reliable or not.
Now, you can make the check reliable:
*) only for releases
*) at any mono build (useful for developers, or you'd have to discard
all the images at each build to be sure you're not using corrupted
images)

The first is best handled with the existing MONO_AOT_FILE_VERSION,
augmented with the mono release version. Note that this data
is built into the mono binary, so it can't never happen that
it's accidentally changed (like a corlib version which can
be different than the one compiled together with mono: which itself
is fine). Basically, it's idiotic to have some other file (corlib)
decide if the ABI of mono is changed, when mono itself knows
it already and there is no way it can get out of sync with itself.
Being reliable at all times can be done by doing the checks
on all the dependencies, so again your proposal doesn't work.

Also, from a security standpoint, I prefer to add the info about the
embedded offsets and other automatically checked data, because it
reduces the chances there is a human error in increasing the aot 
version. Your solution would be a security nightmare.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better