Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: DWARF output parameters indistinguishable from input parameters in debug_info #21100
Both are exported as DW_TAG_formal_parameter at the moment which means it's impossible for a debugger to distinguish between them. Unfortunately there isn't anything (AFAICT) in DWARF v4 that matches the way go does things. Possible solutions:
Export them as DW_TAG_variable
The debugger can then tell which variables are output parameters by looking at the offset from frame base. Cons: it's a (small) abuse of DW_TAG_variable.
The debugger can use this flag to tell which formal parameters are output parameters. Cons: it's an abuse of DW_AT_variable_parameter
I think the first one may be the better option.
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:
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.
I haven't paid the closest attention but I don't think so.
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).
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.