On Mon, Nov 30, 2009 at 11:00 AM, David Hansel <span dir="ltr"><<a href="mailto:hansel@reactive-systems.com">hansel@reactive-systems.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1) In my previous post I included a disassembly of the location where the<br>
crash happens. With some creative grep-ing I was able to find the location<br>
of that code within the assembly code that MLton produces for our program:<br>
<br>I was able to reproduce this with several examples for which the crash<br>
occurs (all of which unfortunately include a large part of our code so<br>
I can not make them available here). The crash always occurs in the<br>
"*applyFFTempFun" call and always because applyFFTempFun is NULL.<br></blockquote><div><br>I agree that that seems to pinpoint the source of the crash.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) As I mentioned before, if I compile the program from the SML<br>
code and just insert a "print" statement in function "get" within<br>
MLton/lib/mlton/sml/mlnlffi-lib/memory/linkage-libdl.sml, the crash<br>
also does not occur. Interestingly, the MLton-produced assembly code<br>
for that version (only change is the "print" statement) does not contain<br>
ANY calls to "applyFFTempFun".<br></blockquote><div><br>More evidence. Although, in this case, I suspect that there is still an indirect call in the assembly code. It simply doesn't go through the temporary variable --- gets allocated and stays in a register. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) Looking at the MLton source code (amd64-generate-transfers.fun), I can see<br>
that calls to "applyFFTempFun" seem to be inserted for "Indirect" FFI calls.<br>
I do not know enough about the code generator or the FFI interface to make<br>
much sense out of this.<br>
However, I can see that the MLTon-produced code with the crash only contains<br>
a call to "applyFFTempFun" (which I assume is created in line 1566 of file<br>
amd64-generate-transfers.fun) but never any code that would set the value<br>
of "applyFFTempFun" (which I assume should be created in line 1183 of file<br>
amd64-generate-transfers.fun).<br>
<br>
Given these observations, does anyone have any suggestions about MLton<br>
debugging options or other ways to shed more light on what might be going<br>
wrong here?<br></blockquote><div><br>Sounds like a bug in the amd64 codegen simplifier and/or register allocator. It seems that somewhere along the line, the definition of the applyFFTempFun variable is being dropped, but the use in the indirect call is being retained. When the register allocator comes along, when it doesn't locally find the def point of applyFFTempFun, it has to fetch the value from the (uninitialized) variable.<br>
<br>Could you compile with "-native-commented 3 -native-split 0 -keep g" and post the basic block that has the call through applyFFTempFun? It will be pretty noisy, but should shed some light on what the native codegen is doing (wrong).<br>
<br></div></div>