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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 2007-07-31 11:28 ------- I cannot reproduce on gcc 4.0.0. I believe Bill is using 3.4.6. + +------- Additional Comments From [EMAIL PROTECTED] 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. + + + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
