You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
garble/testdata/script/reverse.txtar

164 lines
4.1 KiB
Plaintext

# Unknown build flags should result in errors.
! garble reverse -badflag=foo .
stderr 'flag provided but not defined'
garble build
exec ./main
cp stderr main.stderr
# Ensure that the garbled panic output looks correct.
# This output is not reproducible between 'go test' runs,
# so we can't use a static golden file.
grep 'goroutine 1 \[running\]' main.stderr
# Note that ExportedLibMethod isn't obfuscated.
# Note that we use long names like "long_lib.go",
# because an obfuscated filename could realistically end with "lib".
! grep 'ExportedLib(Type|Field)|unexportedMainFunc|test/main|long_main\.go|long_lib\.go' main.stderr
stdin main.stderr
garble reverse .
cmp stdout reverse.stdout
# Ensure that we cleaned up the temporary files.
# Note that we rely on the unix-like TMPDIR env var name.
[!windows] ! grepfiles ${TMPDIR} 'garble|importcfg|cache\.gob|\.go'
! garble build ./build-error
cp stderr build-error.stderr
stdin build-error.stderr
garble reverse ./build-error
cmp stdout build-error-reverse.stdout
[short] stop # no need to verify this with -short
# Ensure that the reversed output matches the non-garbled output.
go build -trimpath
exec ./main
cmp stderr reverse.stdout
# Ensure that we can still reverse with -literals.
garble -literals build
exec ./main
cp stderr main-literals.stderr
stdin main-literals.stderr
garble -literals reverse .
cmp stdout reverse.stdout
# Reversing a -literals output without the flag should fail.
stdin main-literals.stderr
! garble reverse .
cmp stdout main-literals.stderr
-- go.mod --
module test/main
go 1.20
-- long_main.go --
package main
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
import (
"os"
"runtime"
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
"test/main/lib"
)
func main() {
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
unexportedMainFunc()
_, filename, _, _ := runtime.Caller(0)
println()
println("main filename:", filename)
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
}
func unexportedMainFunc() {
anonFunc := func() {
lt := lib.ExportedLibType{}
if err := lt.ExportedLibMethod(os.Stderr); err != nil {
panic(err)
}
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
}
anonFunc()
}
-- lib/long_lib.go --
package lib
import (
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
"io"
"regexp"
"runtime"
"runtime/debug"
)
type ExportedLibType struct{
ExportedLibField int
}
func (*ExportedLibType) ExportedLibMethod(w io.Writer) error {
_, filename, _, _ := runtime.Caller(0)
println("lib filename:", filename)
println()
return printStackTrace(w)
}
func printStackTrace(w io.Writer) error {
// Panic outputs include "0xNN" pointers and offsets which change
// between platforms.
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
// The format also changes depending on the ABI.
// Strip them out here, to have portable static stdout files.
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
rxCallArgs := regexp.MustCompile(`\(({|0x)[^)]+\)|\(\)`)
rxPointer := regexp.MustCompile(`\+0x[0-9a-f]+`)
// Keep this comment here, because comments affect line numbers.
stack := debug.Stack()
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
stack = rxCallArgs.ReplaceAll(stack, []byte("(...)"))
stack = rxPointer.ReplaceAll(stack, []byte("+0x??"))
reverse: support unexported names and package paths (#233) Unexported names are a bit tricky, since they are not listed in the export data file. Perhaps unsurprisingly, it's only meant to expose exported objects. One option would be to go back to adding an extra header to the export data file, containing the unexported methods in a map[string]T or []string. However, we have an easier route: just parse the Go files and look up the names directly. This does mean that we parse the Go files every time "reverse" runs, even if the build cache is warm, but that should not be an issue. Parsing Go files without any typechecking is very cheap compared to everything else we do. Plus, we save having to load go/types information from the build cache, or having to load extra headers from export files. It should be noted that the obfuscation process does need type information, mainly to be careful about which names can be obfuscated and how they should be obfuscated. Neither is a worry here; all names belong to a single package, and it doesn't matter if some aren't actually obfuscated, since the string replacements would simply never trigger in practice. The test includes an unexported func, to test the new feature. We also start reversing the obfuscation of import paths. Now, the test's reverse output is as follows: goroutine 1 [running]: runtime/debug.Stack(0x??, 0x??, 0x??) runtime/debug/stack.go:24 +0x?? test/main/lib.ExportedLibFunc(0x??, 0x??, 0x??, 0x??) p.go:6 +0x?? main.unexportedMainFunc(...) C.go:2 main.main() z.go:3 +0x?? The only major missing feature is positions and filenames. A follow-up PR will take care of those. Updates #5.
3 years ago
_, err := w.Write(stack)
return err
}
-- build-error/error.go --
package p
import "reflect"
// This program is especially crafted to work with "go build",
// but fail with "garble build".
// This is because we attempt to convert from two different struct types,
// since only the anonymous one has its field name obfuscated.
// This is useful, because we test that build errors can be reversed,
// and it also includes a field name.
type UnobfuscatedStruct struct {
SomeField int
}
var _ = reflect.TypeOf(UnobfuscatedStruct{})
var _ = struct{SomeField int}(UnobfuscatedStruct{})
-- reverse.stdout --
lib filename: test/main/lib/long_lib.go
goroutine 1 [running]:
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
runtime/debug.Stack(...)
runtime/debug/stack.go:24 +0x??
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
test/main/lib.printStackTrace(...)
test/main/lib/long_lib.go:32 +0x??
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
test/main/lib.(*ExportedLibType).ExportedLibMethod(...)
test/main/lib/long_lib.go:19 +0x??
main.unexportedMainFunc.func1(...)
test/main/long_main.go:21
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
main.unexportedMainFunc(...)
test/main/long_main.go:25 +0x??
update support for Go 1.17 in time for beta1 Back in early April we added initial support for Go 1.17, working on a commit from master at that time. For that to work, we just needed to add a couple of packages to runtimeRelated and tweak printFile a bit to not break the new "//go:build" directives. A significant amount of changes have landed since, though, and the tests broke in multiple ways. Most notably, the new register ABI is enabled by default for GOOS=amd64. That affected garble indirectly in two ways: there's a new internal package to add to runtimeRelated, and we must make reverse.txt more clever in making its output constant across ABIs. Another noticeable change is that Go 1.17 changes how its own version is injected into the runtime package. It used to be via a constant in runtime/internal/sys, such as: const TheVersion = `devel ...` Since we couldn't override such constants via the linker's -X flag, we had to directly alter the declaration while compiling. Thankfully, Go 1.17 simply uses a "var buildVersion string" in the runtime package, and its value is injected by the linker. This means we can now override it with the linker's -X flag. We make the code to alter TheVersion for Go 1.16 a bit more clever, to not break the package when building with Go 1.17. Finally, our hack to work around ambiguous TOOLEXEC_IMPORTPATH values now only kicks in for non-test packages, since Go 1.17 includes our upstream fix. Otherwise, some tests would end up with the ".test" variant suffix added a second time: test/bar [test/bar.test] [test/bar [test/bar.test].test] All the code to keep compatibility with Go 1.16.x remains in place. We're still leaving TODOs to remind ourselves to remove it or simplify it once we remove support for 1.16.x. The 1.17 development freeze has already been in place for a month, and beta1 is due to come this week, so it's unlikely that Go will change in any considerable way at this point. Hence, we can say that support for 1.17 is done. Fixes #347.
3 years ago
main.main(...)
test/main/long_main.go:11 +0x??
main filename: test/main/long_main.go
-- build-error-reverse.stdout --
# test/main/build-error
test/main/build-error/error.go:18: cannot convert UnobfuscatedStruct{} (value of type UnobfuscatedStruct) to type struct{SomeField int}
exit status 2
exit status 1