Some more cmd/internal/DWARF folks /cc @mdempsky @josharian @dr2chase

I agree that DW_TAG_variable is more appropriate. Why would a debugger care to distinguish between a named return value and a local variable? They seem like essentially the same thing to me.

Why would a debugger care to distinguish between a named return value and a local variable?

Printing the return value of a function on stepout.

Interesting. I'd have thought you'd need a lot more than just this fix to support that. Aren't return values missing from DWARF most of the time? I don't know why that would happen even with optimizations off, but empirically, I don't see ~rN declarations on many functions that definitely return things.

With that use case in mind I might actually be more inclined to use DW_TAG_variable_parameter. I don't like the idea of the debugger having to look at the stack layout to make a decision, especially because that will be difficult to do with a location list.

I read the spec a little more. It does discuss return values a bit:

If the subroutine or entry point is a function that returns a value, then its debugging information entry has a DW_AT_type attribute to denote the type returned by that function.

but of course that's C++-centric and only supports a single return value. Even then, it relies on the debugger understanding the calling convention of the function so that it can actually find the value -- there's no explicit indication of which register(s) it's in. So no help there.

Interesting. I'd have thought you'd need a lot more than just this fix to support that. Aren't return values missing from DWARF most of the time?

I haven't paid the closest attention but I don't think so.

I don't know why that would happen even with optimizations off, but empirically, I don't see ~rN declarations on many functions that definitely return things.

I've looked at a random sampling and they seem to be there (they are only called ~rN when they don't have a name, of course).

I read the spec a little more. It does discuss return values a bit:

one way to go would be to create an artificial struct type with one field for each return parameter and set the DW_AT_data_member_location to be an expression relative to CFA, rather than the usual base address of the containing structure. And then use this type as the DW_AT_type of the function. Named parameters would have to be repeated as DW_TAG_variable or go aware debuggers would have to know to treat the return struct specially.

I think this is a bit too controted and weird. It might be a good way to find bugs in existing debuggers.

Change https://golang.org/cl/71670 mentions this issue: cmd/compile: distinguish args and return values in DWARF