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

[Jacob Lifshay via llvm-dev]

On x86_64, PC is called RIP.
I'm not sure if Clang supports it, but on GCC you can use:
__builtin_extract_return_addr(__builtin_return_address(0))

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Return-Address.html

On Thu, Nov 8, 2018, 10:48 Jordan Rudd via llvm-dev <llvm-dev at lists.llvm.org
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 listllvm-dev at lists.llvm.orghttp://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>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181108/6f69faf2/attachment.html>