https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #42 from Lukas Grätz <lukas.gra...@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #41)
> (In reply to Lukas Grätz from comment #40)
> > It seems that the reason for <optimized out> is ultimately -Og, not this
> > patch. See Bug 78685.
>
> No. When PR78685 would be fixed by adding artificial hidden uses of
> variables at the end of their scopes, this bug would trigger far more often.
> The vars would be live across the calls, so if there would be callee-saved
> registers available, the compiler
> would use them to hold the variables across the calls. And this bug would
> break that.
It could be done that way. But I think a better fix for PR78685 would be to
save the function parameter values to the stack (and than this problem will not
trigger that often). For the following reasons:
(1) Timing for push and mov instructions are similar, so the execution speed
wouldn't be much affected.
(2) A callee needs to somehow restore callee-saved registers, but only if it
returns. So the calling conventions cannot guarantee that callee-saved
registers are saved somewhere for noreturn functions. But of course, if you
disregard this optimization, this would not trigger that often.
(3) Potential register pressure when saving additional variables to
callee-saved registers: If the execution itself no longer needs the value of a
function parameter, there is no need to hold it in a (callee-saved) register
accross calls for a quick access. The stack is sufficient for accessing the
values with the debugger.
(4) The entry values of function parameters should be more helpful, not some
later values. E.g., for
int foo(int i) {
if (i == 42) { h(); }
i = 7;
bar();
}
we would be more interested in the original value of "i" and not the later
value "i = 7" as saved by "artificial hidden uses of variables at the end of
their scopes". By saving original values to the stack before they are modified,
we can keep inspecting the original values.
The helpful backtrace from within bar() could be:
#1 bar()
#2 foo(i@entry=42)
The other version would be a bit counter-intuitive, when the argument to foo
really was i=42:
#1 bar()
#2 foo(i=7)
Btw., function parameters are not normally part of the backtrace (this is just
a nice gdb feature), see Wikipedia:
https://en.wikipedia.org/wiki/Stack_trace
> Anyway, I've posted
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646649.html
> patch which will not revert the #c15/#c24 changes, but guard them with a
> non-default option. People who don't care about the harder debugging can
> use that option in their code, but widely used shared libraries with
> noreturn entrypoints will no longer screw up the debugging for all the
> packages that use them.
Yes, it took me long, but I agree, it would be better to not worsen debugging
experience.
