Description
To call a function that takes arguments (and to read the result) debuggers need to be able to form a stack frame for the function. With knowledge of the argument types and their order, this is pretty straightforward. In an unoptimized program, our DWARF exposes that information in two ways: first, the formal_parameter DIEs are in stack order, so you can infer the layout, and second, they have their home stack slot offsets as their locations.
In an optimized function, neither of these is usable; putPrunedScopes reorders the parameter DIEs, and the location lists aren't reliable enough to use to form the stack frame.
I'm not sure what the right way forward is. We could fix one or both of the above, or introduce a new custom attribute that defines the "canonical" stack slot for a parameter.
Retain DIE order: I don't have a clear sense of why the vars need to be sorted; @thanm will probably know more here. It's a little bit unsatisfying to rely on DIE ordering though.
Improve location lists: This will be very hard to get right without simply giving arguments special treatment. For example, the current location list generation logic will not notice unused arguments at all. It should be straightforward to generate location entries for each parameter at function entry, though, and we could just do that.
New custom attribute: easy, but really feels like giving up. I'd personally rather leave this as a last resort.