https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Thanks. Hmm, tricky. There's no inlining, and debug info is as complete as one could get. The problem is that the registers holding the variables are call-clobbered, and the variables are dead after the call. We emit debug binds right after the call for the variables to the entry values, but the entry values were not saved at the callers either. There's an argument to be made that, at the entry point of foo, the values are still available in the same registers: they haven't been modified yet, and the variables in the enclosing frames were in the same registers up to the point of the call, so one could infer they're still there, but maybe that's asking too much of a debugger. It would have to somehow know that none of the prologue insns changed the registers in a meaningful way to conclude that they still hold the variables that were passed in, to then conclude that the variables in the enclosing frames, that lived in the same registers up to the point of the call, held those values too. And that's the analysis for bar, because, for main, it would again have to somehow know that the value did not change between entry and the call, which is not given by debug info (all we know is that the *location* didn't change), to infer that the registers that held the value up to calling bar still hold the same values, that were held by the corresponding variables. Perhaps if we emitted locations indicating that the variable is unchanged, by naming the entry value as a location for the entire range, a debugger could more easily make that sort of reasoning and find suitable values. It still feels like pushing it a bit, though.
