[Mono-bugs] [Bug 457108] Fields with fixed RVA should be retained at that RVA
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Wed Dec 10 22:40:08 EST 2008
https://bugzilla.novell.com/show_bug.cgi?id=457108
User rkumpera at novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=457108#c3
Rodrigo Kumpera <rkumpera at novell.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lupus at novell.com
--- Comment #3 from Rodrigo Kumpera <rkumpera at novell.com> 2008-12-10 20:39:58 MST ---
I talked with Paolo and, from what I understood, the issue is that to fix your
problem we might break a lot of other code and the InitializeArray
optimization.
Then I decided to take a look at how serious this problem really is.
The current JIT uses the RVA pointer directly to implement the
RuntimeHelpers::InitializeArray optimization and for big endian archs, it
always falls back to the icall for types bigger than 1 byte.
The icall is wrong on big endian arch for anything but primitive types as
blitable structs with explicit layout can use the RVA magic.
Anyway, this is not an issue because all managed code compilers only use fields
with RVA for initializing arrays of primitive types.
The truth is that either nobody uses code that load/store to fields with RVA or
never tried on big endian archs because the code in
mono_class_create_runtime_vtable doesn't fix endianess issues.
But, anyway, what we have here are two bugs:
-The first one, CrossAppDomainDataSharing, shows that the RVA data must be per
image and not per domain.
-The second one shows that we don't support pointer arithmetic over .data items
as the standard tells.
I think we should definitely fix the first one, which has the bonus of reduced
memory usage.
The second one is somewhat questionable, but I'm in favor of fixing it for this
given set of reasons:
-It should cause zero impact to our users, as our current behavior is broken
under big endian archs and nobody noticed;
-It's not a security vector as storing to a RVA field is not verifiable;
-It will make us more specs compliant and better match .NET's behavior;
-Memory alignment might be an issue, but can be fixed by the JIT;
-Uses less memory; and
-The implementation is simpler than the current one.
Paolo, what do you think about?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list