The PCs you got from runtime runtime.Callers are the function return addresses, which is the instruction immediately after the CALL instruction. The runtime function subtracts the PC by one so it will get the PC of the CALL instruction, which is usually what people want.

The debug/gosym package uses the actual PC instead. It should not do the -1 because it should not assume the input PC is a return PC, nor you're trying to get back to the CALL instruction. If you want that semantic, you'd want to do the -1 yourself. Thanks.

That's a bit surprising because the *Func reported corresponds to the correct function, but the file and line do not. Is that ever the expected result for any PC? I'm happy to do the subtraction myself in that case, but the API is a bit awkward since there's no way to avoid the *Func lookup twice (once to determine whether to subtract -1, and then once more within (*Table).PCToLine).

The function is correct because it is the same function.

The runtime function and the debug/gosym package serve different purpose. The runtime function is specific to traceback. The debug/gosym package is not. You can look up for arbitrary PCs. Only for the traceback case the -1 is the right thing to do. If you know you are getting the PCs from a backtrace, you probably can always do the -1 (the runtime function has a condition to handle signals, like if you're taking a traceback from a signal handler triggered by a panic. If you know that's not your case you probably can skip the check). Otherwise never.

I'm not sure what you mean by "it is the same function". The file and line information refer to a completely different file, so those don't seem consistent with the *Func in any plausible interpretation. Either way, if you believe this is correct I have no problem doing the subtraction myself.

Based on the documentationruntime.FuncForPC also suggests it supports looking up arbitrary PCs; is that different from the use case for debug/gosym?

With inlining, the file and line number can change, but it is still in the same (machine code) function.

Yes, runtime.FuncForPC can be used to look up arbitrary PCs. But I'm not sure I understand your question.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

Thanks @cherrymui. I'm still not sure I understand what you mean. Let me give you an example.

In my code I'm calling database/sql/.(*DB).QueryRowContext, which is defined in sql.go#L1777.

I then capture a stack trace (from within this function call, using a custom database driver). If I inspect the stack trace within the Go runtime (using runtime.FuncForPC), I see, as I would expect, a stack frame with:

file: "/path/to/goroot/src/database/sql/sql.go"
func: "database/sql.(*DB).QueryRowContext"
line: 1778

However, when I take the corresponding PC, load the symbol table from the binary, and look it up with debug/gosym.(*Table).PCToLine, I instead get:

file: "/path/to/goroot/src/database/sql/sql.go"
func: "my.module/pkg/path.Foo"
line: 1778

That is, the file and line information is correct, but the func is wrong. The func comes from the parent stack frame, that called database/sql.(*DB).QueryRowContext. This happens regardless of whether or not I subtract 1 from the PC.

What is it about the runtime that allows it to correctly map the PC to the correct function, while debug/gosym cannot? They both get the file and line number correct.

I noticed in FuncForPC (symtab.go#L630) that the runtime looks up inlining information, while I cannot see corresponding code in debug/gosym. Is that the cause? Is this information available in the symbol table but not used by debug/gosym?