Jordan Rudd via llvm-dev
2018-Nov-08 01:22 UTC
[llvm-dev] Passing stack pointer to statepoint-gc
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181108/53e15406/attachment.html>
Philip Reames via llvm-dev
2018-Nov-08 15:27 UTC
[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 > 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/756b5af2/attachment.html>
Jordan Rudd via llvm-dev
2018-Nov-08 18:47 UTC
[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%7C75fc1886795644fde63508d6458ea8d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636772876347540128&sdata=rqOd0XZEm7VTKcxviSbjybgpSKgDL3lCU%2Fzq32fi4O0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181108/8acd0a64/attachment-0001.html>