<div dir="ltr">Hi all,<div><br></div><div>I've been using the llvm.gcroot intrinsic combined with the generated machine stack maps to attempt to do precise GC without the use of a shadow stack. (This is all research work on a novel language so I have no existing system to compare against, for the record.)</div>
<div><br></div><div>Most of my test suite is working and tracing stack roots correctly. However, there seem to be some scenarios where the stack maps do not agree with reality. I suspect this has to do with SP manipulations during the execution of some particular piece of code, but it's hard to gather evidence to corroborate this theory.</div>
<div><br></div><div>I did notice that the stack map is invariant (at the LLVM level) with respect to which safe point is actually reached within the host function; i.e. if I have Foo() with two safe points and manipulate the SP between point A and point B, the stack map becomes bogus because nothing accounts for the change to the SP.</div>
<div><br></div><div>I'm not sure if this scenario is the actual explanation, but I've also noticed that occasionally the stack map will just seem wrong; it will mark certain stack slots as live roots which are outside the bounds of the actual machine stack frame, for instance. This obviously causes the tracing phase of the GC to wander off into random bits of memory and (usually) crash shortly thereafter.</div>
<div><br></div><div><br></div><div>Unfortunately it seems like there is painfully little documentation on how the stack maps work or are meant to be used, so I was hoping to dig up some tribal knowledge from the list.</div>
<div><br></div><div>My strategy for interpreting the maps currently looks like this:</div><div><br></div><div>if (stack offset <= 0)</div><div>   pointer to root = start of current stack frame + offset</div><div>else</div>
<div>   pointer to root = end of the stack frame "above" current stack frame + offset + size of frame pointer + size of return address pointer</div><div><br></div><div><br></div><div>The reason for this split is that when the offset is negative it seems to refer to one span of stack space, whereas when it is positive it appears to be based from a different SP entirely. I found this approach by brute force, i.e. generating a large number of test cases and mapping out the stack on paper until the offsets revealed some semblance of a pattern.</div>
<div><br></div><div>However, I'm suspicious about my interpretation of the two cases because of the aforementioned mis-flagging of roots, but again there seems to be no documentation whatsoever describing how to actually find a stack address based on a value in the stack map.</div>
<div><br></div><div><br></div><div><br></div><div>Any/all advice would be much appreciated!</div><div><br></div><div><br></div><div><br></div><div>Thanks,</div><div><br></div><div><br></div><div><br></div><div> - Mike</div>
<div><br></div><div><br></div></div>