cmd/internal/obj: drop Filesym from DwarfAbstractFunc
PutAbstractFunc doesn't use FnState.Filesym, so it isn't needed, but
more importantly it is misleading. DwarfAbstractFunc is frequently used
on inlined functions from outside the current compilation unit. For
those function, ctxt.fileSymbol returns nil, meaning it probably isn't
safe to use if the original compilation unit could also generate an
abstract func with the correct file symbol.
Change-Id: I0e6c76e41d75ac9ca07e0f775e49d791249e1c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458198
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
diff --git a/src/cmd/internal/obj/dwarf.go b/src/cmd/internal/obj/dwarf.go
index 121a9f6..3f4c6e8 100644
--- a/src/cmd/internal/obj/dwarf.go
+++ b/src/cmd/internal/obj/dwarf.go
@@ -433,15 +433,10 @@
scopes, _, startPos := ctxt.DebugInfo(s, absfn, curfn)
_, startLine := ctxt.getFileSymbolAndLine(startPos)
dwctxt := dwCtxt{ctxt}
- // TODO(prattmic): this returns nil for symbols outside of the current
- // package because s.Func() is empty. This doesn't matter because
- // PutAbstractFunc doesn't use Filesym. Use startPos or remove.
- filesym := ctxt.fileSymbol(s)
fnstate := dwarf.FnState{
Name: s.Name,
Importpath: myimportpath,
Info: absfn,
- Filesym: filesym,
Absfn: absfn,
StartLine: startLine,
External: !s.Static(),
