Description
Go version
go version go1.22.3 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/.cache/go-build'
GOENV='/home/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.3'
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 -ffile-prefix-map=/tmp/user/1000/go-build3235747414=/tmp/go-build -gno-record-gcc-switches'What did you do?
I tried to view the value of different types of const values with dlv.
Code:
package main
import "fmt"
const myValueStr = "try"
const myValueInt = 12
const myValueFloat = 1.2func main() {
fmt.Println(myValueStr, myValueInt, myValueFloat)
}
What did you see happen?
I obtain a different behavior depending of the type of the constant.
Debug:
dlv exec main
(dlv) print main.constValueInt
12
(dlv) print main.constValueStr
Command failed: could not find symbol value for main
(dlv) print main.constValueFloat
Command failed: could not find symbol value for main
Analyze:
objdump -W main | grep -i constV
<2547> DW_AT_name : main.constValueInt
By analyzing Go ompiler code, we can see into src/cmd/compile/internal/gc/obj.go:163 that's the func dumpGlobalConst exports only integer const "for now" (ie. comment line 172).
What did you expect to see?
I expect to see all const values.
Debug:
dlv exec main
(dlv) print main.constValueInt
12
(dlv) print main.constValueStr
"try"
(dlv) print main.constValueFloat
1.2
Analyze:
objdump -W main | grep -i constV
<2547> DW_AT_name : main.constValueInt
<2547> DW_AT_name : main.constValueStr
<2547> DW_AT_name : main.constValueFloat
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Relationships
Development
Participants
Activity
randall77 commentedon May 31, 2024
@aarzilli
aarzilli commentedon May 31, 2024
I think this had been discussed somewhere in another issue, but I can't find it, so I'll restate it: when I did the thing that exports integers to dwarf I didn't include string constants because I thought it would bloat too much the executable size.
Benoit12345 commentedon May 31, 2024
I found your message about the binary size here: https://go-review.googlesource.com/c/go/+/61019 (comment Patchset 5 | Sep 08, 2017 10:01 PM ).
I understand the perf impact on binary size. In another hand, that's quite difficult to understand for developpers why some const are watched and some others cannot be consulted into an IDE debug session.
If I understand well (sorry, I'm not an expert of the Go compiler), the dwarf debug_info struct is still not compressed ? maybe it could be a solution if impacts on compile time are not so huge... And/Or maybe the increasing binary size could be "acceptable" while compiling optimizations are not enabled ?
aarzilli commentedon May 31, 2024
It is compressed but it doesn't change my opinion on the matter: integer constants are useful because we can use them to the value of variables, which would otherwise be very opaque. The same does not go for string constants. But keep in mind that this is just my opinion.
[-]src/cmd/compile/internal/gc/obj.go: dumpGlobalConst dumps only integer constant[/-][+]cmd/compile: only integer consts are exported in DWARF[/+]mknyszek commentedon Jun 3, 2024
CC @golang/compiler
[-]cmd/compile: only integer consts are exported in DWARF[/-][+]cmd/compile: add string constants to DWARF[/+]Zxilly commentedon Jun 9, 2024
I'm working on go-size-analyzer and try to extract some info from dwarf. I also met this problem. Sometimes constant string can be very large if the programmer use the tool like bindata. But the info of this part was ommitted from dwarf.
Zxilly commentedon Jun 9, 2024
Storing the full const string would lead to excessive size, maybe we could store the offset in const against
go:string.*? Or create a new type of dwarf pointing to theStringHeader?gopherbot commentedon Aug 9, 2024
Change https://go.dev/cl/604101 mentions this issue:
cmd/compile,cmd/link: export string global consts to DWARFgopherbot commentedon Jun 1, 2025
Change https://go.dev/cl/677915 mentions this issue:
cmd: emit dwarf for string constants