https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534

--- Comment #33 from Lukas Grätz <lukas.gra...@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #32)
> (In reply to Lukas Grätz from comment #31)
> > Even when I compile a simple program with gcc -O2 -g:
> > 
> > #include <stdlib.h>
> > int main(int argc, char** argv) {
> >     abort();
> > }
> > 
> > 
> > I still get an "argc=<optimised out>":
> 
> Sure, debugging info in optimized code is best effort.
> 
> > Yes, for a better debugging, it would be nice if optimised code would just
> > not be optimised... But this goes against optimization.
> 
> The significant difference between other optimizations and this one is
> that normal optimizations affect the debuggability of the optimized function.
> This one affects the debuggability of all callers as well, even if they are
> compiled in a way that should make them more debuggable.
> Normally, if debugging optimized code doesn't work out, one can simply
> rebuild that code with -O0 or -Og to make it more debuggable.
> Here one would also need to rebuild all the shared libraries it uses.

When the debugger is inside the debuggable -O0 or -Og compiled function, we
would see all parameters and current variable values. However, in the bt
example, we are in another function. So the parameters are only available at
best effort.

I just noticed that for my simple.c example above, I get "argc=<optimised out>"
even with -Og. However, when breakpoint is somewhere else,

(gdb) break main
(gdb) run
(gdb) bt

I get the correct "argc=1". The same applies to your example with "break baz".
It is just not guaranteed that gdb is able to reconstruct function parameters
when we are in some other function.

Reply via email to