http://bugzilla.novell.com/show_bug.cgi?id=494567
User [email protected] added comment http://bugzilla.novell.com/show_bug.cgi?id=494567#c9 --- Comment #9 from Raja Harinath <[email protected]> 2009-04-16 11:21:56 MDT --- The patch works, but is probably somewhat of a red-herring I think. Basically, since your patch changes offsets of instructions everywhere, this particular bug might've been hidden, since it's highly dependent on the exact bit pattern of the surrounding code and the bit pattern of the relative jump. My understanding is that the bug is with a 0xe8 call instruction (x86_call_code), not with a 0xff call instruction (x86_call_membase). Maybe this should go into emit_call() instead? Also, I was wondering if it was worth the effort to do something like this instead of always emitting nops: static const guint32 dummy_regs [NUMBER_OF_REGISTERS]; int ntries = 0; retry: old_code = code; x86_call_...(code, ...); if (mono_arch_get_vcall_slot_addr (code, (guint32*)dummy_regs)) { /* ugh, this absolute call looks just like as a virtual/interface call */ code = old_code; /* let's pad with a nop and see ... */ x86_nop (code); if (++ntries > 5) g_warning ("%s: padding with too many nops? (%d)", mono_method_full_name (current_method), ntries); goto retry; } -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
