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

[Jordan Rudd via llvm-dev]

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/728f51b9/attachment.html>