go-delve/delve · error

unsupported piece kind

Error message

unsupported piece kind

What it means

CreateCompositeMemory builds a composite MemoryReaderOverOperation from DWARF location pieces (RegisterPiece/ImmediatePiece). The switch over piece kinds has no handling for other op.DWARFPiece kinds, so encountering one panics — it means the location expression produced a piece type the composite-memory constructor cannot materialize.

Source

Thrown at pkg/proc/mem.go:167

		case op.AddrPiece:
			buf := make([]byte, piece.Size)
			if _, err := mem.ReadMemory(buf, piece.Val); err != nil {
				return nil, fmt.Errorf("could not read %d bytes from address %#x: %v", piece.Size, piece.Val, err)
			}
			cmem.data = append(cmem.data, buf...)
		case op.ImmPiece:
			buf := piece.Bytes
			if buf == nil {
				sz := max(piece.Size, 8)
				if piece.Size == 0 && i == len(pieces)-1 {
					piece.Size = arch.PtrSize() // DWARF doesn't say what this should be
				}
				buf = make([]byte, sz)
				binary.LittleEndian.PutUint64(buf, piece.Val)
			}
			cmem.data = append(cmem.data, buf[:piece.Size]...)
		default:
			panic("unsupported piece kind")
		}
	}
	paddingBytes := int(size) - len(cmem.data)
	if paddingBytes > 0 && paddingBytes < arch.ptrSize {
		padding := make([]byte, paddingBytes)
		cmem.data = append(cmem.data, padding...)
	}
	return cmem, nil
}

func (mem *compositeMemory) ReadMemory(data []byte, addr uint64) (int, error) {
	addr -= mem.base
	if addr >= uint64(len(mem.data)) || addr+uint64(len(data)) > uint64(len(mem.data)) {
		return 0, errors.New("read out of bounds")
	}
	copy(data, mem.data[addr:addr+uint64(len(data))])
	return len(data), nil
}

View on GitHub (pinned to a23773e6c3)

Solutions

1. Reproduce with a minimal program and report to go-delve/delve (this is an unhandled DWARF piece kind)
2. Rebuild the binary with optimizations disabled (-gcflags="-N -l") to get simpler location expressions
3. Try a newer delve version — piece-kind coverage improves over time
4. Inspect the variable's pieces to confirm the unsupported kind via 'print -v'

// inspect variable location first
v, err := evalVariable(name)
if err != nil || len(v.LocationExpr) > 1 { /* multi-piece location: printing may panic */ }

func() {
    defer func() {
        if r := recover(); r != nil {
            val = nil
            err = fmt.Errorf("cannot evaluate composite variable: %v", r)
        }
    }()
    val, err = evalVariable(name)
}()

When it happens

Trigger: Evaluating a variable whose DWARF location list yields a piece kind other than op.RegisterPiece or op.ImmPiece (e.g. certain stack/FB-register or implicit-location pieces) when creating composite memory for a register-based variable.

Common situations: Inspecting variables with unusual optimized-away or multi-piece locations; compiler-generated DWARF (newer gc or gcc/clang output) using piece kinds delve's constructor doesn't handle.

Related errors

• wrong real type for map
• Invalid type %s in slice array
• Could not read from instruction buffer
• Could not unread byte
• Could not read byte

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/04959eff1044c6a7. Report an issue: GitHub.