[llvm-dev] Passing stack pointer to statepoint-gc

[Philip Reames via llvm-dev]

Yes, program counter.  Also known as instruction pointer.  On X86-64, 
RIP register.


Philip


On 11/8/18 10:48 AM, Jordan Rudd wrote:
> Program counter?
> ------------------------------------------------------------------------
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jordan 
> Rudd via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* Thursday, November 8, 2018 10:47 AM
> *To:* Philip Reames; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Passing stack pointer to statepoint-gc
> Sorry, what does "PC" mean here?
> ------------------------------------------------------------------------
> *From:* Philip Reames <listmail at philipreames.com>
> *Sent:* Thursday, November 8, 2018 7:27 AM
> *To:* Jordan Rudd; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Passing stack pointer to statepoint-gc
>
> Jordon,
>
>
> First of all, StackMaps are keyed by PC, not by SP.  Each entry 
> corresponds to given location within the generated code.
>
>
> This isn't something you want to do in generated code. Your runtime 
> should be responsible for this.  If you support stack walking or back 
> traces for any purpose, you should already have the code to identify 
> the PC for a suspended frame on the stack.
>
>
> If you don't, the easiest approach will be to use a assembly stub 
> between your generated code and your C/C++ runtime code which grabs 
> the PC from the stack, and moves it into an argument register.
>
>
> Philip
>
>
> On 11/7/18 5:22 PM, Jordan Rudd via llvm-dev wrote:
>> Hi,
>>
>> I'm trying to use the statepoint-example strategy to build a simple 
>> garbage collector. After using the PlaceSafepoints 
>> and RewriteStatepointsForGC passes, I can successfully generate a 
>> stack map in my binary and call into my runtime's gc poll.
>>
>> As far as I can tell, I need the stack pointer at the point of the 
>> poll to find the correct frame in the stack map. I'm having trouble 
>> doing that.
>>
>> One library I looked at online (statepoint-utils) simply defines a 
>> helper function written in assembly that pushes the RSP register to 
>> RDI before calling into the runtime, so that the runtime gc polling 
>> function can read it as a parameter.
>>
>> I was trying to do the same thing except in llvm, so from my 
>> gc.safepoint_poll definition, I tried adding these lines:
>>
>> declare void @runtime_safepoint_poll(i64)
>> declare i64 @llvm.read_register.i64(metadata) #1
>> !0 = !{!"rsp\00"}
>>
>> ; Read the stack pointer and pass it to our polling function (assumes 
>> x64)
>> define void @gc.safepoint_poll() {
>>   %stackpointer = call i64 @llvm.read_register.i64(metadata !0)
>>   call void @runtime_safepoint_poll(i64 %stackpointer)
>>   ret void
>> }
>>
>> attributes #1 = { "gc-leaf-function" nounwind readnone }
>>
>> Note that the target triple is x86_64-pc-windows-msvc.
>>
>> When I test this, the values that come from reading RSP are never in 
>> the address space of the module. Like, not even close.
>>
>> As far as I can tell, this /should /work, and I'm a little stymied as 
>> to why I'm getting back garbage. Do I misunderstand the read_register 
>> call here?
>>
>> Thanks,
>> Jordan
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7C01%7C%7Cbb88aac921f247a9080b08d645aaa91e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636772996613513985&sdata=IQb%2B6Gs6UMJYw9iNiQpbM5veWc8%2F4SVcDStnSqE5DLQ%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181108/9ed96439/attachment.html>