golang/go · error

unqualified symbol name: %v

Error message

unqualified symbol name: %v

What it means

Returned by PutAbstractFunc when s.Name begins with the literal prefix `"".` — the symbol's package qualifier is empty, meaning the name was not fully qualified (package path missing). DWARF abstract-origin function DIEs must carry a fully-qualified name so concrete inlined instances can reference them unambiguously; an unqualified name breaks that contract and is rejected before emission.

Source

Thrown at src/cmd/internal/dwarf/dwarf.go:1214

// Emit DWARF attributes and child DIEs for an 'abstract' subprogram.
// The abstract subprogram DIE for a function contains its
// location-independent attributes (name, type, etc). Other instances
// of the function (any inlined copy of it, or the single out-of-line
// 'concrete' instance) will contain a pointer back to this abstract
// DIE (as a space-saving measure, so that name/type etc doesn't have
// to be repeated for each inlined copy).
func PutAbstractFunc(ctxt Context, s *FnState) error {
	if logDwarf {
		ctxt.Logf("PutAbstractFunc(%v)\n", s.Absfn)
	}

	abbrev := DW_ABRV_FUNCTION_ABSTRACT
	Uleb128put(ctxt, s.Absfn, int64(abbrev))

	fullname := s.Name
	if strings.HasPrefix(s.Name, `"".`) {
		return fmt.Errorf("unqualified symbol name: %v", s.Name)
	}
	putattr(ctxt, s.Absfn, abbrev, DW_FORM_string, DW_CLS_STRING, int64(len(fullname)), fullname)

	// DW_AT_inlined value
	putattr(ctxt, s.Absfn, abbrev, DW_FORM_data1, DW_CLS_CONSTANT, int64(DW_INL_inlined), nil)

	// TODO(mdempsky): Shouldn't we write out StartPos.FileIndex() too?
	putattr(ctxt, s.Absfn, abbrev, DW_FORM_udata, DW_CLS_CONSTANT, int64(s.StartPos.RelLine()), nil)

	var ev int64
	if s.External {
		ev = 1
	}
	putattr(ctxt, s.Absfn, abbrev, DW_FORM_flag, DW_CLS_FLAG, ev, 0)

	// Child variables (may be empty)
	var flattened []*Var

View on GitHub (pinned to b6b368adc5)

Solutions

1. Rebuild on a stable released Go toolchain.
2. Report with the reproducer at https://go.dev/issue.
3. If using -overlay or exotic build modes, try a normal build to see if the path resolves.
4. Temporarily disable inlining/DWARF to confirm linkage works without abstract DIEs.

When it happens

Trigger: The compiler/linker passes a function name to PutAbstractFunc whose package path resolved to empty (the `"".` placeholder). This reflects a downstream symbol-name plumbing bug where packagepath was not set, not a user Go-source error.

Common situations: Encountered with packages whose import path computation yields empty (path-agnostic builds, unusual build modes like -overlay, plugin/shared builds, or tip regressions in the symbol table). Essentially an internal invariant violation.

Related errors

• dwarf: null reference in %d
• dwarf: unsupported attribute form %d / class %d
• multiple toplevel scopes
• %s doesn't contain type split
• %s -Wl,-V failed: %v %s

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/ce81f25da0b07576. Report an issue: GitHub.