go tools now resolve the real path of the input file #1943
Comments
|
Looking at whole Which is weird since we pass trimpath to |
|
After doing some bash-fu, I could narrow down the following packages for stdlib that seem impacted: They all have assembly files, which I'm guessing is the reason. |
|
Ok so the reason is that the trimpath is: Which is not the path that ends up in the dwarf. |
|
Alright so, for |
|
I managed to fix Now only the |
|
I've opened a PR for the stdlib part, however, for the file part, I'm not convinced this is the right approach, even though it works on macOS: diff --git a/go/tools/builders/compile.go b/go/tools/builders/compile.go
index 2b6d050..d0003bf 100644
--- a/go/tools/builders/compile.go
+++ b/go/tools/builders/compile.go
@@ -38,6 +38,23 @@ type archive struct {
importPath, importMap, file string
}
+func findExecrootPath(sandboxPath string) string {
+ realPath, _ := filepath.EvalSymlinks(sandboxPath)
+ realPath = abs(realPath)
+ if realPath == sandboxPath {
+ return sandboxPath
+ }
+
+ sandboxPathComponents := strings.Split(sandboxPath, string(filepath.Separator))
+ realPathComponents := strings.Split(realPath, string(filepath.Separator))
+ for i, part := range sandboxPathComponents {
+ if part != realPathComponents[i] {
+ return "/" + filepath.Join(realPathComponents[:i]...)
+ }
+ }
+ return sandboxPath
+}
+
func run(args []string) error {
// Parse arguments.
args, err := readParamsFiles(args)
@@ -122,6 +139,8 @@ func run(args []string) error {
*packagePath = goFiles[0].pkg
}
+ execRootPath := findExecrootPath(goFiles[0].filename)
+
// Check that the filtered sources don't import anything outside of
// the standard library and the direct dependencies.
_, stdImports, err := checkDirectDeps(goFiles, archives, *packageList)
@@ -163,7 +182,15 @@ func run(args []string) error {
filenames = append(filenames, f.filename)
}
goargs = append(goargs, filenames...)
- absArgs(goargs, []string{"-I", "-o", "-trimpath", "-importcfg"})
+ absArgs(goargs, []string{"-I", "-o", "-importcfg"})
+
+ for i := 0; i < len(goargs); i++ {
+ if goargs[i] == "-trimpath" {
+ goargs[i+1] = execRootPath
+ i++
+ }
+ }
+
cmd := exec.Command(goargs[0], goargs[1:]...)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr |
|
Thanks for digging into this issue and sending a fix. Before I merge #1945 (which looks fine by the way), I'd like to understand exactly what's going wrong and why our tests didn't catch this. I haven't actually been able to reproduce the problem though. What is your execution platform (you mentioned macOS). Target platform? Any other configuration changes ( |
|
Actually, this goes further than that, as |
|
When I tried this earlier, I wasn't able to reproduce on darwin or linux amd64. From the messages here, it looks like you're building for |
|
I don't know how to fix the problem with So until |
|
See the sample run: |
|
I traced it to packages using Related issue for |
|
Ok so I'm trying wrapped I'm passing the sandbox path to the wrapper with an environment var. |
|
Now the only remaining path for stdlib is this one, and I think it has to do with The weird thing is also: But then: |
|
So I've found the root cause of the path leaking for It's been fixed in |
|
NDK19 is So |
|
It also doesn't work with apple's clang: So appart from post-processing the file (which could be an option), I'm not sure what to do :( |
|
One way I could do this would be to post process the file's DWARF string table and remove all mentions of the sandbox path. |
|
I'd prefer not to post-process files in If I understand correctly, the bug is in the Android NDK toolchain. Is it possible to use a wrapper inside the C toolchain that invokes clang differently or post-processes the .o file at that point? |
|
Indeed the bug is in all The thing is: it's kind of easy to post-process in Go thanks to What I was thinking was wrapping |
|
That sounds fine. So that wrapped cc would be configured as the compiler |
|
I'm not sure configuring it as |
|
You may want to write your own CROSSTOOL and point to it with I have no idea how a custom CROSSTOOL would interact with Android and iOS though. |
|
On Apple, it has been fixed on Xcode 10.2.1. Will try Android. |
|
Closing old issues. Sounds like this is fixed now. |
It seems
go installandgo tool compilenow resolve the real path of the input file, causing sandbox and real paths to leak into the binary.See this
dwarfdumpsample:Notice the first file is not in the sandbox, while the other is in the external bazel folder, not in the sandbox, which was:
I'm not sure how to fix that properly....
The text was updated successfully, but these errors were encountered: