Symbol of const string are not exported by compiler

[Benoît Marguerie]

Hello All,

I discovered a "strange" behavior doing a simple operation. 

I defined 2 const : one integer and one string. With delve (or other debugger), I'm able to consult the const integer value but not the const string value. Delve team explained me that the go compiler doesn't export symbol of const string.

Sorry for the newbee's question but is there anybody knowing why the symbol can be exported for an integer but not for a string ?

BR,

Benoît

[Jan Mercl]

Please include a code example that you're investigating using delve.
I, for one, cannot infer enough information from your post to be sure
what exactly is the problem and hence if the observed is - or is not -
an expected outcome.

[Benoît Marguerie]

Of course!
The code can be really simple like this:

const myValueStr = "try"
const myValueInt = 12

func DoSomething() {
   fmt.Println("Instruction only to put a breakpoint")
}

and the result with delve:

(dlv) print %v myValueInt
12
(dlv) print %v myValueStr
Command failed: could not find symbol value for myValueStr

Benoit

[Benoît Marguerie]

or, in a easier way, a full "copy/paste" example of code:

package main

import "fmt"

const myValueStr = "try"
const myValueInt = 12

func main() {

fmt.Println("Instruction only to put a breakpoint")
}

[Kurtis Rader]

Your question should have included more information such as the Go version. Nonetheless, I don't see how Delve is able to resolve "myValueInt" in your example. I modified your code to include non-const versions of the symbols:

package main

import "fmt"

const constValueStr = "abc"
const constValueInt = 12
const constValueFloat = 1.2

var varValueStr = "def"
var varValueInt = 13

func main() {
        fmt.Println(constValueStr, constValueInt, constValueFloat, varValueStr, varValueInt)
}

I put that code in a file named "x.go" and compiled it with "go build x.go". The "strings" command shows both "varValue" symbols but neither "constValue" symbols:

elvish> strings - x | grep varValue

_main.varValueInt

_main.varValueStr

elvish> strings - x | grep constValue

Exception: grep exited with 1

  [tty 156]:1:15-29: strings - x | grep constValue

Delve is able to resolve three of the five symbols:

elvish> dlv exec x

Type 'help' for list of commands.

(dlv) print main.varValueInt

13

(dlv) print main.constValueInt

12

(dlv) print main.constValueFloat
Command failed: could not find symbol value for main

(dlv) print main.varValueStr

(unreadable could not read string at 0x100086f47 due to protocol error E08 during memory read for packet $m100086f47,3)

(dlv) print main.constValueStr

Command failed: could not find symbol value for main

It is not obvious how Delve is able to resolve "main.constValueInt" since that string does not appear in the binary according to the "strings - x" command. So I think the more interesting question is how Delve is able to resolve the "main.constValueInt" symbol but not the two other const symbols.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c938f107-9bca-4b8e-a10c-f8deef396c87n%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Benoît Marguerie]

Good question !

But delve mainly extracts its symbols from Dwarf info. And when I try to get them with your code, I obtain this:

~/tmp$ objdump -W main | grep -i constV
    <2547>   DW_AT_name        : main.constValueInt

We can see that the compiler puts some debug tags for const int values but not for the others.

From here, I've searched into Go SDK for dwarf information and I found in the compiler sources this (file src/cmd/compile/internal/gc/obj.go:163-189 func dumpGlobalConst):

// only export integer constants for now
if !t.IsInteger() {
return
}

So, for the moment, it seems to be a deliberate limitation of Go compiler.

Many thanks for your help @Jan and @Kurtis !

Benoît

NB: just for information, I'm working with Go 1.22.3, dlv 1.22.1 , objdump 2.38)

[Benoît Marguerie]

Just for information, I've written an issue on go compiler to follow this evolution: https://github.com/golang/go/issues/67744