CC @thanm

I took a look. I think things are working mostly as intended, within the limitations we have as part of our compiler design and how things work with optimization turned on.

The DWARF variable location expressions emitted by the compiler when optimization is on are basically "best effort" at the moment -- we do our best to emit correct DWARF when we can, but there are going to be cases where the optimizer will confuse the DWARF emitter and it can't generate anything reasonable (or anything at all), and other cases where we miss variables completely.

The incoming Go code looks like:

L7:  //go:noinline
L8:  func testFunc(a, b, c int) (d int, e int, f int) {
L9:  	return c, b, a
L10: }

The assembly we generate looks like this:

00000  (8) TEXT "".testFunc(SB), ABIInternal
00006 (+9) MOVQ AX, DX
00007  (9) MOVQ CX, AX
00008  (9) MOVQ DX, CX
00009  (9) RET

The "+" tag on line (+9) on the first instruction indicates that this spot is marked in the DWARF line table as being the start of a statement (hence this is where the debugger will stop).

Semantics for Go return parameters are that they initially have a zero value, then take on other values if assigned to by name or by a return statement. In this case at line 9, the return hasn't yet executed, so there is no specific location we can point to (register or memory) that contains the value we need for a variable like "d".

There are compilers out there that will recognize portions of the lifetime of a variable that are constant, and emit multi-range location expressions where some of the ranges hold locations (register or stack) and other ranges hold constants (GCC does a pretty good job of this). The Go compiler currently doesn't try to do this, since it adds complexity to the value tracking machinery. If it can't see a specific register or chunk of memory that holds the value of a named variable, it won't emit a debug location for it.

It's true that once the "MOVQ CX, AX" has executed, then we have a concrete location for "d", so we could generate a location list that started at that spot. It's not clear how useful that would be, however, since the only way to get to that spot is to step instruction by instruction (something most users of debuggers are not going to do).

For return parameters in general I think the Go compiler has always done a pretty substandard job, even with the register ABI. Prior to the register ABI work, it would simply put out a location description pointing the stack location and be done with it. So for a function like

//go:noinline
 func testFunc(a, b, c int) (d int, e int, f int) {
   d = 101
   d += G          /* SPOT1 */
   println(d)      /* SPOT2 */
   return c, b, a
 }
 var G int

If you were to stop on SPOT1 or SPOT2 above, printing "d" would just show an incorrect value of zero.

When the register ABI work was completed, there were a lot more opportunities during late call lowing for return params to get "lost in the sauce", which is what's happening now in many cases.

So just to summarize: yes, we could definitely be doing better in terms of emitting DWARF location expressions for return params, but fixing this is something that would require some concerted design and implementation work, it isn't a case where we could resolve the issue with small tweaks to the existing code.