go-fuzz
go-fuzz copied to clipboard
go-fuzz-build: embed support packages in binary?
It'd be nice if we could embed the support packages go-fuzz-build needs into the binary, rather than relying on the go tool being able to find them on disk. See discussion at https://github.com/golang/go/issues/30515#issuecomment-480612782 and the following few comments.
https://go-review.googlesource.com/c/tools/+/172409/ added "package overlay" support to go/packages. This is a reminder issue to experiment with whether it would suffice for embedding our support packages, and if so, to start using it.
@josharian Is the thinking that this would be the best approach (now that overlays of entire packages are supported):
Use codegen to embed the support package into go-fuzz-build and use go/packages overlays (ugh, plus IIUC this doesn’t work because you can only overlay files, not entire packages)
That is excerpt from your comment at https://github.com/golang/go/issues/30515#issuecomment-480612782
That’s what I was thinking, yes. I definitely still have an “ugh” reaction to it, but it should be reliable and simple for go-fuzz users.
Most likely this can be done with the go-bindata-assetfs package, which is already vendored.
Here is a sample go:generate in the current go-fuzz that could be used as a starting point for anyone interested in investigating this.
https://github.com/dvyukov/go-fuzz/blob/1810d380ab9c2786af00db592f86d83063216ed0/go-fuzz/main.go#L23-L26
@josharian fyi, I filed #279 to track a potentially related issue.
I suspect you might have been using https://github.com/kevinburke/go-bindata installed locally on your machine in the most recent go generate run in 1e7aea5... does that seem plausible?
If #279 is indeed an issue, do you think it would be OK to treat that as a separate pre-existing issue that does not gate any attempt here (in other words, to rely on a local installation of go-bindata in order to help embed the support packages here), or do you think #279 should be addressed before trying to resolve this issue here?
All that said, #279 might just be me being confused, so maybe it is a non-issue.
No need to gate progress here on #279, although I suspect that in practice you might choose to. Up to you.
Thanks for looking into this.