[Mono-bugs] [Bug 82095][Nor] Changed - GetExecutingAssembly reports the wrong assembly

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by billholmes54 at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=82095

--- shadow/82095	2007-07-31 11:28:21.000000000 -0400
+++ shadow/82095.tmp.14380	2007-07-31 23:16:32.000000000 -0400
@@ -94,6 +94,65 @@
  __builtin_frame_address (0), which is a gcc function. You might have
 a buggy gcc version.
 
 
 ------- Additional Comments From joncham at gmail.com  2007-07-31 11:28 -------
 I cannot reproduce on gcc 4.0.0. I believe Bill is using 3.4.6.
+
+------- Additional Comments From billholmes54 at gmail.com  2007-07-31 23:16 -------
+I am seeing this on two different machines.
+Fedora gcc version 3.4.6 and
+Red Hat gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
+
+I did take another look at this and maybe the SP field of ctx is not
+getting set to the right value due to a gcc bug as you mentioned.
+
+What I am guessing is that __builtin_frame_address is the right thing
+to use for the rbp register however I question if is right for the
+rsp.  I am assuming that it is the intent to populate ctx with values
+that reflect the registers on the chip.  (Is that a fair assumption?)
+ I am looking at the register values in gdb and after the init call
+the ctx values, rbp and rsp, both match the register rbp printed from
+gdb.  This value is past the end of stack used for comparison for the
+while condition.  Therefore the while loop is never entered.
+
+Are the rsp and rbp supposed to be set to the same values (or at least
+close?)  On my fedora machine they are not.
+
+Fedora machine
+
+rbp	0x2aaaadb9df30
+rsp	0x40424d80
+ctx.rbp	0x2aaaadb9df30
+ctx.rsp	0x2aaaadb9df30
+
+However on another SUSE machine 32 bit gcc 3.3.3 
+
+ebp	0x40cda20c
+esp	0x40cda164
+ctx.ebp	0x40cda20c
+ctx.esp	0x40cda20c
+
+I will see if I can get Jonathan to report his values as well.
+
+My question is does it ever make sense to see a sp greater than, and
+in this case that much greater than, the bp?  Or have I just verified
+your suspicion that this is a gcc error?
+
+Changing this code to a do while and stepping around in gdb I do not
+notice any other code inside the loop that depends on rsp so I am
+hoping that ignoring this check for the initial check for the loop is
+safe.  Going through the loop always reassigns the ctx values (through
+mono_find_jit_info) that will work with the break condition next time
+around.
+
+Before I stated that make check hangs with a do while change and since
+then I discovered that it will hang without the change.  Just not all
+the time.  I then applied this patch to another 64 bit machine showing
+the problem and I get a clean make check.  Maybe this is a suitable
+workaround to a gcc problem?  Probably you can suggest something safer
+to try.  Hopefully we do not have to scrap our version of gcc.  
+
+Let me know if there is any other info I can provide.
+
+  
+