cmd/go: -trimpath not trimming some C source file paths

[JetSetIlly]

What version of Go are you using (go version)?

go version go1.20.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/Go/go-current/go/bin"
GOCACHE="/home/.cache/go-build"
GOENV="/home/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/Go/go-current/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/Go/go-current/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/Go/go-current"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/Go/go-current/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build632438867=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I was trying the "new" -trimpath feature and found that some system path information was inserted into the executable binary.

Most paths were trimmed successfully but some paths to C source files were not trimmed.

The problem can be seen when building this project: https://github.com/inkyblackness/imgui-go-examples

In the cmd/example_sdl_opengl3 directory

> go build -tags 'sdl' -trimpath .
> strings example_sdl_opengl3 | grep home

/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_draw.cpp
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_truetype.h
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_demo.cpp
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_rectpack.h
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui.cpp
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui.h
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_internal.h
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_widgets.cpp
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_tables.cpp
/home/Go/go-current/go/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_textedit.h

I'm not sure this is really a bug but I can't see these strings in the DWARF data (when dumped with readelf) nor do they exist as literal strings in the source.

What did you expect to see?

All system paths used during the build and included in the binary, to be trimmed.

What did you see instead?

Some system paths included in the binary have not been trimmed.

[JetSetIlly]

Details of GCC toolchain

gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

[bcmills]

I'm able to reproduce this using gcc 12.2.0.

$ go get github.com/inkyblackness/imgui-go-examples/cmd/example_sdl_opengl3

$ go build -tags 'sdl' -trimpath github.com/inkyblackness/imgui-go-examples/cmd/example_sdl_opengl3
# github.com/inkyblackness/imgui-go/v4
In file included from wrapper.cpp:7:
.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_draw.cpp: In function ‘void ImFontAtlasBuildPackCustomRects(ImFontAtlas*, void*)’:
.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_draw.cpp:2623:11: warning: ‘void* memset(void*, int, size_t)’ specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
 2623 |     memset(pack_rects.Data, 0, (size_t)pack_rects.size_in_bytes());
      |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ strings example_sdl_opengl3 | grep $(go env GOMODCACHE)
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_draw.cpp
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_truetype.h
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_demo.cpp
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_rectpack.h
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui.cpp
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui.h
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_internal.h
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_widgets.cpp
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imgui_tables.cpp
/tmp/tmp.W5C2Bye2U3/.gopath/pkg/mod/github.com/inkyblackness/imgui-go/v4@v4.7.0/imgui/imstb_textedit.h

[matloob]

(from debugging with bcmills offline) It sounds like we should use --file_prefix_map in the invocations of the compiler, assuming the compiler version supports it.

[ianlancetaylor]

Note that we already use -fdebug-prefix-map. For GCC -ffile-prefix-map implies -fdebug-prefix-map. I'm not clear on where these strings are appearing if it's not the debug info.

[bcmills]

Using objdump -s we found that the strings that end up in the object file correspond to uses of the IM_ASSERT macro in the C and C++ codebase (they're in the .rodata.str1.8 section of the object file, and located adjacent to strings that look like the C expressions passed to IM_ASSERT).

There are several different definitions of the IM_ASSERT macro in the codebase, but our hypothesis is that they're ending up evaluating the __FILE__ macro to produce the strings that end up in the code, possibly here:
https://github.com/inkyblackness/imgui-go/blob/bed7fdfcba8248960e3d8a6aa251bc8665340d9d/wrapper/ConfigOverride.h#L11

From https://reproducible-builds.org/docs/build-path/, it looks like -fdebug-prefix-map fixes the references in the DWARF debug data but not the __FILE__ macros, and that switching to -ffile-prefix-map (or adding -fmacro-prefix-map) would fix those as well.

[ianlancetaylor]

Oh, I see, the strings are coming from calls to assert in the C++ code. That could be fixed by using -fmacro-prefix-map, which, like -fdebug-prefix-map, is implied by -ffile-prefix-map. Probably changing all the -fdebug-prefix-map options to -ffile-prefix-map would fix this.

The -ffile-prefix-map option was added in GCC 8 (2018). The -fmacro-prefix-map option was added then as well. -fdebug-prefix-map is older, added in GCC 4.3 (2008). So I guess we should only switch from -fdebug-prefix-map to -ffile-prefix-map if the latter is supported.

(Probably you already knew all that.)

[ianlancetaylor]

Sorry, crossed paths. You did know all that.

[matloob]

This was fixed by https://go-review.git.corp.google.com/c/go/+/478455.