internal/fakecgo: generalize and update trampoline generation

[gdams]

Updates gen.go to generate trampolines for arm, arm64, loong64, and riscv64, 386 alongside amd64.

What issue is this addressing?

What type of issue is this addressing?

feature

What this PR does | solves

• Added architecture definitions for additional platforms.
• Simplified instruction generation: removed custom call instructions in favor of a standard CALL instruction which works across the supported architectures (including simplified syntax for loong64 and riscv64).
• Updated build constraints in generated files to !cgo only, relying on file naming conventions (ztrampolines_$GOARCH.s) for architecture selection.
• Regenerated ztrampolines_*.s files to reflect these changes. internal/fakecgo: generalize and update trampoline generation

[hajimehoshi]

Interesting, but does this change mean our callback.go will be much more different from the original one in the Go repository?

[qmuntal]

Interesting, but does this change mean our callback.go will be much more different from the original one in the Go repository?

The approach hasn't changed, it's just that the linknames and the variable declarations have been moved into another file. It's true that some comments are lost in the process, although those comments are copied verbatim from upstream, so one can look there to understand what's happening. The only comment that should be kept (in my opinion) is the one that is specific to purego, the one that start with // In Go 1.20 the race detector was rewritten to pure Go. We could also add a note in callbacks.go pointing to zcallbacks.go.

[qmuntal]

Note that this not only simplifies adding and maintaining architectures, but will also be used as part of the #343 fix.

[hajimehoshi]

My concern was this would make it harder to synchronize callbacks.go and other files with the original ones. Even in the current situation, callbacks.go and the original one is quite different. This might be ok but I am not sure. @TotallyGamerJet What do you think?

[gdams]

My concern was this would make it harder to synchronize callbacks.go and other files with the original ones. Even in the current situation, callbacks.go and the original one is quite different. This might be ok but I am not sure. @TotallyGamerJet What do you think?

Happy to revert the callback.go templating if you're really against this although I do see some benefit to templating it, especially as it grows!

[TotallyGamerJet]

Ehh I'm not confident that templating callbacks.go is really necessary. I rather wait until it gets uncomfortably large and then consider it

[gdams]

Ehh I'm not confident that templating callbacks.go is really necessary. I rather wait until it gets uncomfortably large and then consider it

Shall I revert the callback changes then and just leave the trampolines?

[TotallyGamerJet]

Shall I revert the callback changes then and just leave the trampolines?

Yes, I'm still trying to figure out how I feel about the trampoline generation. If we can't generate the entire file I'm leaning to not doing it at all because then it becomes confusing if changes should be made to the static trampoline file or the generated one