cmd/link: dumpdep output is missing 'from'

[kruskall]

Go version

go1.24.2

Output of go env in your module/workspace:

GOVERSION='go1.24.2'

What did you do?

Consider the following:

package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hi!")
}

built with go build -gcflags="all=-N -l" -ldflags=-dumpdep .

What did you see happen?

Most of the output is of the form from -> to:

e.g.

main.main -> fmt.Println
fmt.Println -> os.Stdout
fmt.Println -> go:itab.*os.File,io.Writer
fmt.Println -> fmt.Fprintln
fmt.Fprintln -> fmt.newPrinter
fmt.Fprintln -> fmt.(*pp).doPrintln
fmt.Fprintln -> fmt.(*pp).free

However some of the lines seem to be missing a from value.

 -> go:info.*fmt.fmt
 -> go:info.*fmt.buffer
 -> go:info.fmt.buffer
 -> go:info.[6]uint8
 -> go:info.*fmt.pp
 -> go:info.io.Writer
 -> go:info.[]interface {}
 -> go:info.reflect.Value
 -> go:info.fmt.fmtFlags
 -> go:info.fmt.Formatter
 -> go:info.fmt.GoStringer
 -> go:info.fmt.Stringer
 -> go:info.int16
 -> go:info.internal/fmtsort.SortedMap
 -> go:info.internal/fmtsort.KeyValue
 -> go:info.reflect.Type

What did you expect to see?

Unless I'm missing something If the parent is missing I'd expect at least a _ (

go/src/cmd/link/internal/ld/deadcode.go

Line 370 in dad4f39

from := "_"

) but instead the output shows an empty string.

[cherrymui]

Some symbols don't have a name, like some auxiliary DWARF symbols. That is probably what you see above.

Ideally we want to print to which symbol the auxiliary symbol is attached, but I don't think we have that information handy, if we don't want to build a reverse lookup map just for printing. Alternatively, perhaps we can print the symbol index, e.g.

somefunc -> <unnamed sym 123>
<unnamed sym 123> -> go.info.somevariable

[cherrymui]

cc @thanm

[thanm]

I agree that the dumpdep output handling of aux and unnamed symbols is not great.

I've worked on better dumping options (e.g. https://go-review.googlesource.com/c/go/+/599436) but never managed to get things to the point where I thought it was ready for review. I use CL 599436 routinely when I am debugging linker problems on my own, it shows symbol indices as part of linker dumpdep, and with linker debug options you can get it to show aux symbol relationships (e.g. here).

[mknyszek]

Any reason not to move something like CL 599436 forward?

[cherrymui]

CL 599436 is mostly for debugging the linker itself, instead of providing diagnostics for user programs. It will dump a whole lot of information.

We could borrow some parts from it, like printing the symbol indices and aux relationships, for this particular diagnostic.