On Fri, Feb 21, 2020 at 7:38 AM Iskander Sharipov <quasil...@gmail.com> wrote: > > If the original question is not clear, I can re-phrase it like this: what > happens if a function marked with NO_LOCAL_POINTERS contains heap pointers on > its frame? > > My understanding is that these pointers will not count as something that is a > pointer and if there will be no other pointers to that data, it will be > claimed by GC. But if there are other pointers that keep that data reachable, > what are other consequences that can happen?
When the code calls gofunc1, it may find that there is not enough stack space, which will cause the runtime to copy the stack to a new location. When copying the stack the runtime will examine all pointers on the stack, and, if they point to locations elsewhere on the stack, adjust them to point to the new stack location. So if the pointers passed to your function happen to point to locations on the stack, and you use NO_LOCAL_POINTERS, then they will not be adjusted, and your program will have dangling pointers leading to memory corruption or other problems. Ian > On Friday, February 21, 2020 at 4:12:01 PM UTC+1, Iskander Sharipov wrote: >> >> Hi all. >> >> I have an asm function that is defined like this: >> >> // func f(x *T1, y *T2) >> TEXT ·f(SB), 0, $32-16 >> NO_LOCAL_POINTERS >> // It does call a few Go functions, this is why >> // I need some frame space, to put their arguments there. >> MOVQ <arg1>, 0(SP) >> MOVQ <arg2>, 8(SP) >> CALL ·gofunc1(SB) >> MOVQ 16(SP), AX // Save result >> // ...more such calls, args take up to 32 bytes. >> RET >> >> It has 2 pointer arguments and frame with size=32 bytes. >> All that frame space is only used for function call arguments, >> asm function itself does not spill data to the stack. >> >> Arguments to Go functions can contain pointers. >> All of them come from the 2 f() arguments (x and y). >> >> So the question is: how safe it's to use NO_LOCAL_POINTERS here? >> >> If NO_LOCAL_POINTERS is removed, I can't do a CALL, since runtime needs a >> stack map. >> >> Note that the asm code is simplified, but all statements given above still >> hold: stack frame only >> holds pointers that are reachable via f() arguments and it's only used to >> pass arguments to (normal) Go functions. >> >> This sentence from the asm docs adds more confusion: >>> >>> Because stack resizing is implemented by moving the stack, the stack >>> pointer may change during any function call: even pointers to stack data >>> must not be kept in local variables. >> >> >> I'm not sure what it means by "local variables". When doing asm, you can >> only imagine local variables as stack-saved values. >> >> I found this part of code that gives some insights, but I can't make a >> reliable conclusion about my case out of that. >> >> Thank you in advance. :) > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/83b51508-0e2b-4d5b-80a7-97a3931ec5e4%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWQQGGdKx3u%2BU1pW%3DSoGBX%2B595g_6jCuKtQ_bhbD6vGNQ%40mail.gmail.com.
