-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: DWARF output parameters indistinguishable from input parameters in debug_info #21100
Comments
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. |
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:
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. |
Change https://golang.org/cl/71670 mentions this issue: |
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.
Set DW_AT_variable_parameter
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.
cc @heschik @hyangah @derekparker
The text was updated successfully, but these errors were encountered: