[Mono-bugs] [Bug 494567] r131501 breaks compilation of System.Windows.Forms_test_net_1_1.dll

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Thu Apr 16 13:21:57 EDT 2009


http://bugzilla.novell.com/show_bug.cgi?id=494567

User harinath at hurrynot.org added comment
http://bugzilla.novell.com/show_bug.cgi?id=494567#c9





--- Comment #9 from Raja Harinath <harinath at hurrynot.org>  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.


More information about the mono-bugs mailing list