-
Notifications
You must be signed in to change notification settings - Fork 78
fix deadcode disabling in Go #30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Avoid embedding reflect.Type and its Method() method because exposing it disables deadcode removal in linker. Signed-off-by: Tonis Tiigi <[email protected]>
|
@taowen PTAL 🙏 |
|
@tonistiigi Are you sure it's meaningful? Can you suggest a simple sample main.go importing this package such that |
alternatively sometimes |
|
@tonistiigi yes, but can you provide a minimal main.go? From whydeadcode README:
I saw a similar "problem" in another package but when I tried to reproduce it in isolation, it wasn't a problem anymore. |
I don't have time to work on this. What I can show you is that this does have a significant effect on the build above. The difference of these builds is only the patch in this PR (you can't repro this as more fixes are needed, most notably awful
This is true, but the current case is not a false positive. It is entirely possible that there are other cases that mess up deadcode in this package that this PR does not fix. I only followed the call path in buildx. The output of |
|
Definitely not a minimal example, but I can confirm updating to the merged commit fixes it for the https://github.com/DataDog/datadog-agent binaries, see DataDog/datadog-agent#32527 (comment) for the size diff (note that the PR is a hacky one where I just comment out the uses of template 😄) Without the update, the output of Details
Actually this is something I fixed in aarzilli/whydeadcode#3, if you use the latest it should be correct. |
|
@pgimalac To complement that, can you comment out the use of text/template but undo this change and see if the binary size remains large? I want to make sure this has an actual effect. I've made a similar PR in jszwec/csvutil#73 but then I couldn't reproduce the effect. |
|
For example, given this program: package main
import (
"fmt"
"reflect"
)
type embedding struct {
reflect.Type
foo string
}
type s struct {
}
func (s) Foo() {}
func main() {
t := reflect.TypeOf(s{})
a := embedding{Type: t, foo: "bar"}
fmt.Println(a)
//m := a.Method(0)
//fmt.Println(m)
}I'm only Am I missing something? |
|
That's actually what I did above, if I just comment out the update of I tried to make a minimal example a couple months ago but wasn't able to, I think it has to be complex enough (multi module at least) so that the linker can't figure out which methods are used... |
Avoid embedding reflect.Type and its Method() method because exposing it disables deadcode removal in linker.
https://tip.golang.org/src/cmd/link/internal/ld/deadcode.go#L395