Failure on Go1.17 and above

[madLifeZPC]

Hi,

It seems this solution only works on Go below or equal to 1.16. On 1.17 or above, it panics:

unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x111d265]

goroutine 34 [running]:
runtime.throw({0x116555b, 0x194})
    /Users/zhaopc/sdk/go1.17.2/src/runtime/panic.go:1198 +0x71 fp=0xc000106da8 sp=0xc000106d78 pc=0x1034531
runtime.sigpanic()
    /Users/zhaopc/sdk/go1.17.2/src/runtime/signal_unix.go:742 +0x2f6 fp=0xc000106df8 sp=0xc000106da8 pc=0x1048e56
github.com/cocotyty/dpig.myCallReflect(0x1131c32, 0x4, 0x0)
    /Users/zhaopc/opensource/dpig/component.go:226 +0x25 fp=0xc000106e20 sp=0xc000106df8 pc=0x111d265
github.com/cocotyty/dpig.myCallReflect(0x1, 0xc000106e78, 0xc000106e60)
    <autogenerated>:1 +0x2f fp=0xc000106e48 sp=0xc000106e20 pc=0x112fa4f
github.com/cocotyty/dpig.makeFuncStub1()
    /Users/zhaopc/opensource/dpig/asm_gen_amd64.s:28 +0x46 fp=0xc000106e78 sp=0xc000106e48 pc=0x1129546
github.com/cocotyty/dpig.makeFuncStub1()
    <autogenerated>:1 +0x5 fp=0xc000106e80 sp=0xc000106e78 pc=0x112fa85
github.com/cocotyty/dpig.main()
    /Users/zhaopc/opensource/dpig/try.go:24 +0x199 fp=0xc000106f60 sp=0xc000106e80 pc=0x1128ed9
github.com/cocotyty/dpig.Test_main(0x0)
    /Users/zhaopc/opensource/dpig/try_test.go:8 +0x17 fp=0xc000106f70 sp=0xc000106f60 pc=0x1129157
testing.tRunner(0xc000118ea0, 0x11706f8)
    /Users/zhaopc/sdk/go1.17.2/src/testing/testing.go:1259 +0x102 fp=0xc000106fc0 sp=0xc000106f70 pc=0x10dffa2
testing.(*T).Run·dwrap·21()
    /Users/zhaopc/sdk/go1.17.2/src/testing/testing.go:1306 +0x2a fp=0xc000106fe0 sp=0xc000106fc0 pc=0x10e0caa
runtime.goexit()
    /Users/zhaopc/sdk/go1.17.2/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc000106fe8 sp=0xc000106fe0 pc=0x1064d81
created by testing.(*T).Run
    /Users/zhaopc/sdk/go1.17.2/src/testing/testing.go:1306 +0x35a

Did some exploration, it turns out this solution relies on assembly to acquire the method parameters address through FP and then pass it to the call, would it be affected by the new convention of passing arguments through register instead of stack mentioned in https://go.dev/doc/go1.17#compiler? After some debugging, I found on go1.17 the var fc = *(**fnContext)(ptr) will always result in an invalid value, which means the pointer is actually wrong. Is it possible to fix this issue? Not sure whether it is still possible to acquire all arguments in asm on 1.17 and above.

[cocotyty]

There is a lot of work that needs to be done to fix this problem.

[madLifeZPC]

Indeed. I did a naive try and managed to change the assembly logic to match the latest mechanism of passing arguments and successfully trigger the reflect function and capture the method receiver, however, the current challenge is reflect.callReflect itself does not seem to handle the case for method call, whose first argument is always the receiver object. This is ease to hack before go1.17 since all you need to do is just add a 8 offset to the stack frame, after 1.17, it seems to be very challenging to hack the register. There is no other way I can come up with except for copy the reflect internal logic and ignore the first argument, but that also seems to be very fragile and result in unforeseen problems. Another thing, this solution is also slow due to the heavy usage of reflection, comparing with calling original function directly, it has 4 times latency. I am currently looking at other solutions.

[cocotyty]

Indeed. I did a naive try and managed to change the assembly logic to match the latest mechanism of passing arguments and successfully trigger the reflect function and capture the method receiver, however, the current challenge is reflect.callReflect itself does not seem to handle the case for method call, whose first argument is always the receiver object. This is ease to hack before go1.17 since all you need to do is just add a 8 offset to the stack frame, after 1.17, it seems to be very challenging to hack the register. There is no other way I can come up with except for copy the reflect internal logic and ignore the first argument, but that also seems to be very fragile and result in unforeseen problems. Another thing, this solution is also slow due to the heavy usage of reflection, comparing with calling original function directly, it has 4 times latency. I am currently looking at other solutions.

You are right!

[spacether]

Did you find any other solutions?

[ovechkin-dm]

Indeed. I did a naive try and managed to change the assembly logic to match the latest mechanism of passing arguments and successfully trigger the reflect function and capture the method receiver, however, the current challenge is reflect.callReflect itself does not seem to handle the case for method call, whose first argument is always the receiver object. This is ease to hack before go1.17 since all you need to do is just add a 8 offset to the stack frame, after 1.17, it seems to be very challenging to hack the register. There is no other way I can come up with except for copy the reflect internal logic and ignore the first argument, but that also seems to be very fragile and result in unforeseen problems. Another thing, this solution is also slow due to the heavy usage of reflection, comparing with calling original function directly, it has 4 times latency. I am currently looking at other solutions.

You can create new function type with receiver via reflect.FuncOf, and then pass resulting type to reflect.MakeFunc. This way the registers will be correctly aligned with function arguments.