Skip to content
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

Closed
aarzilli opened this issue Jul 20, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@aarzilli
Copy link
Contributor

commented Jul 20, 2017

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

@odeke-em odeke-em changed the title cmd/compile: output parameters indistinguishable from input parameters in debug_info cmd/compile: DWARF output parameters indistinguishable from input parameters in debug_info Jul 21, 2017

@odeke-em

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

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

@odeke-em odeke-em added this to the Go1.10 milestone Jul 21, 2017

@heschik heschik added the Debugging label Jul 21, 2017

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2017

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.

@aarzilli

This comment has been minimized.

Copy link
Contributor Author

commented Jul 21, 2017

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.

@heschik

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2017

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.

@aarzilli

This comment has been minimized.

Copy link
Contributor Author

commented Jul 21, 2017

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.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 18, 2017

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

@gopherbot gopherbot closed this in 3ba818c Oct 18, 2017

@golang golang locked and limited conversation to collaborators Oct 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.