Record GOROOT in precompiled C archives

[Quim Muntal]

I've noticed that C file paths located at GOROOT are elided when building Go binaries using cgo, which makes it impossible for debuggers to find those files. This was done on purpose in CL 380915 to avoid having wrong paths when distributing the Go toolchain, as the real final GOROOT is not known when building it.

AFAIK, the Go toolchain no longer ship precompiled C archives, but they are built and cached as needed. This means that the right final GOROOT is known when building those C archives, and therefore we can partially revert CL 380915 (keeping the regression test). Am I missing something?

[Bryan C. Mills]

Given that the GOROOT packages are now rebuilt as needed, I think it would be ok to include GOROOT when the `-trimpath` flag is not set.

That would mean that setting or unsetting `-trimpath` would rebuild more dependencies than it did before, but that's probably an acceptable tradeoff for better debug information.

On Fri, Mar 24, 2023 at 11:43 AM Quim Muntal <quimm...@gmail.com> wrote:

I've noticed that C file paths located at GOROOT are elided when building Go binaries using cgo, which makes it impossible for debuggers to find those files. This was done on purpose in CL 380915 to avoid having wrong paths when distributing the Go toolchain, as the real final GOROOT is not known when building it.

AFAIK, the Go toolchain no longer ship precompiled C archives, but they are built and cached as needed. This means that the right final GOROOT is known when building those C archives, and therefore we can partially revert CL 380915 (keeping the regression test). Am I missing something?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/6e3b0eae-cd5c-420a-aee3-e9568716fbc4n%40googlegroups.com.