support go:linkname directives to method funcs #656
Comments
|
Can you provide a way for us to reproduce the failure? You could build with We don't support gccgo at this point, so that part is not really relevant. |
|
Thank you for the reply 🙏🏻 The project is pretty comprehensive, but will try to reproduce it via the suggested |
|
Also see #595, if you'd like my help there. |
|
I think I found the cause, it's the goccy package. The following code also reports on |
|
Ok, I changed the How could I debug this? Namely, when I ran it with |
|
That run-time panic looks like a different bug to me, can you please open a separate issue with the bug template? |
|
Sorry am not dev, still learning, will do so... Can this one be closed? |
|
No need to close it - this bug is also valid :) |
mvdan
changed the title
mvdan
changed the title
This is not common, but it is done by a few projects. Namely, github.com/goccy/go-json reached into reflect's guts, which included a number of methods: internal/runtime/rtype.go 11://go:linkname rtype_Align reflect.(*rtype).Align 19://go:linkname rtype_FieldAlign reflect.(*rtype).FieldAlign 27://go:linkname rtype_Method reflect.(*rtype).Method 35://go:linkname rtype_MethodByName reflect.(*rtype).MethodByName [...] Add tests for such go:linkname directives pointing at methods. Note that there are two possible symbol string variants; "pkg/path.(*Receiver).method" for methods with pointer receivers, and "pkg/path.Receiver.method" for the rest. We can't assume that the presence of two dots means a method either. For example, a package path may be "pkg/path.with.dots", and so "pkg/path.with.dots.SomeFunc" is the function "SomeFunc" rather than the method "SomeFunc" on a type "dots". To account for this ambiguity, rather than splitting on the last dot like we used to, try to find a package path prefix by splitting on an increasing number of first dots. This can in theory still be ambiguous. For example, we could have the package "pkg/path" expose the method "foo.bar", and the package "pkg/path.foo" expose the func "bar". Then, the symbol string "pkg/path.foo.bar" could mean either of them. However, this seems extremely unlikely to happen in practice, and I'm not sure that Go's toolchain would support it either. I also noticed that goccy/go-json still failed to build after the fix. The reason was that the type reflect.rtype wasn't being obfuscated. We could, and likely should, teach our assembly and linkname transformers about which names we chose not to obfuscate due to the use of reflection. However, in this particular case, reflect's own types can be obfuscated safely, so just do that. Fixes burrowers#656.
This is not common, but it is done by a few projects. Namely, github.com/goccy/go-json reached into reflect's guts, which included a number of methods: internal/runtime/rtype.go 11://go:linkname rtype_Align reflect.(*rtype).Align 19://go:linkname rtype_FieldAlign reflect.(*rtype).FieldAlign 27://go:linkname rtype_Method reflect.(*rtype).Method 35://go:linkname rtype_MethodByName reflect.(*rtype).MethodByName [...] Add tests for such go:linkname directives pointing at methods. Note that there are two possible symbol string variants; "pkg/path.(*Receiver).method" for methods with pointer receivers, and "pkg/path.Receiver.method" for the rest. We can't assume that the presence of two dots means a method either. For example, a package path may be "pkg/path.with.dots", and so "pkg/path.with.dots.SomeFunc" is the function "SomeFunc" rather than the method "SomeFunc" on a type "dots". To account for this ambiguity, rather than splitting on the last dot like we used to, try to find a package path prefix by splitting on an increasing number of first dots. This can in theory still be ambiguous. For example, we could have the package "pkg/path" expose the method "foo.bar", and the package "pkg/path.foo" expose the func "bar". Then, the symbol string "pkg/path.foo.bar" could mean either of them. However, this seems extremely unlikely to happen in practice, and I'm not sure that Go's toolchain would support it either. I also noticed that goccy/go-json still failed to build after the fix. The reason was that the type reflect.rtype wasn't being obfuscated. We could, and likely should, teach our assembly and linkname transformers about which names we chose not to obfuscate due to the use of reflection. However, in this particular case, reflect's own types can be obfuscated safely, so just do that. Fixes #656.
What version of Garble and Go are you using?
$ garble version mvdan.cc/garble v0.9.0 Build settings: -compiler gc CGO_ENABLED 1 GOARCH amd64 GOOS linux GOAMD64 v1 $ go version go version go1.19.5 linux/amd64What environment are you running Garble on?
go envOutputWhat did you do?
Gargle runs on small project w/o problems, but now ran into a bit bigger project and I get the following error after running simply
garble build project.go.If I try with different compiler, i.e.
garble build -compiler gccgo project.go, the following error occur:go list error: exit status 2: # golang.org/x/exp/constraints
What did you expect to see?
To build it like
go build project.go, which works fine.What did you see instead?
The above mentioned errors.
The text was updated successfully, but these errors were encountered: