finalizing 64-bit mixed mode issues

[Paul Gofman]

regarding p. 3, please ignore my suggestion to change mscoree cleanup on
process exit. I found a true reason for crash and it is more severe then
just crash on exit though easy to fix in Mono. The problem concerns the
whole sgen garbage collection under x86_64 when using libmono like Wine
does. It can be easily reproduced by a trivial .Net assembly calling
GC.Collect() twice in Main (the assembly should be compiled and run as
64bit, 32bit is OK). The problem is sgen_marksweep.c bitcount(mword)
function which does it wrong when __GNUC__ is defined (I am attaching a
trivial patch which fixes it). I will try to submit it to Mono upstream
somehow.

On 02/09/2016 05:16 PM, Paul Gofman wrote:
> Hi Vincent,
>
> I currently have all my cases with 64-bit mixed assemblies calling pure
> .Net working just fine under Wine/Mono (well, almost fine, it looks like
> I found a bug in Mono System.Windows.Forms cs code, but this is a
> separate issue), but not with vanilla ones. The following issues are not
> fixed upstream yet:
>
> 1. Loading 32-bit pure assemblies in 64-bit code. The patch you attached
> some time ago (which includes CorValidateImage implementation) works
> just fine for me. Do you have any plans for pushing it upstream soon?
>
> 2. Mono JIT compiler PTR/I8 issues. I've extended a bit your test case
> and updated the patch in the Mono bug info. While we are waiting for
> some reply on this in Mono maybe it is possible to send my patch for
> wine-mono? I am not sure that it is fully correct (it would in fact
> require to get familiar with the whole JIT code generation path to make
> sure), but I presume it is safe to use as:
>  - the changes relate to 64-bit code generation only, 32 bit is not
> affected anyhow;
>  - as for 64 bit, the changes solely extend what instruction/call
> parameters are considered valid for JIT code generator. If something was
> valid without this patch, it will not be affected. If something was
> invalid and gets touched by the patch incorrectly for some cases, it
> will likely result in segfault instead of 'invalid il code' exception in
> the worst case.
>
> 3. 64-bit .Net programs constantly crashing on process exit for me (this
> affects test case with exe and dll you sent previously as well). The
> crash happens in Mono GC finalizing code triggered by
> System.Process.Exit call from mscoree CorExitProcess. The immediate
> crash reason is that some objects touched by GC through its hash tables
> get NULL vtable pointer somewhere earlier in deinitialization. I did not
> find the exact reason for this yet, but looked at coree.c in Mono where
> they just call ExitProcess without anything else, and comment says:
> "FIXME: This is not currently supported by the runtime.". If I do the
> same in mscoree CorExitProcess it fixes the issue with crash. Do you
> think this is a right way to do for now? If yes I could send a patch for
> this.
>
> Thanks,
>     Paul.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sgen-fix-bit-counting-in-mword.patch
Type: text/x-patch
Size: 800 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160209/d8d3e023/attachment-0001.bin>