I would say that this is limited to a targeted Go version and architecture. For example, the filter checks for the goroutine pointer on `r28` which is correct for arm64 but not universally true.
Any changes to the struct layouts, stack, or heap layouts would also cause failures in these lookups. E.g., in Go 1.17, many functions now use direct register mappings for arguments rather than always placing arguments in the stack.
Would need to thoroughly vet compatability with each new Go version before using something like this in production.
Comments
I would say that this is limited to a targeted Go version and architecture. For example, the filter checks for the goroutine pointer on `r28` which is correct for arm64 but not universally true.
Any changes to the struct layouts, stack, or heap layouts would also cause failures in these lookups. E.g., in Go 1.17, many functions now use direct register mappings for arguments rather than always placing arguments in the stack.
Would need to thoroughly vet compatability with each new Go version before using something like this in production.