On 02/12/2015 08:26 AM, Eli Zaretskii wrote: >> Date: Wed, 11 Feb 2015 18:07:42 +0200 >> From: Eli Zaretskii >> Cc: dancol@dancol.org, dak@gnu.org, emacs-devel@gnu.org >> >>> From: "Stephen J. Turnbull" >>> Cc: David Kastrup , >>> Eli Zaretskii , >>> emacs-devel@gnu.org >>> Date: Wed, 11 Feb 2015 22:22:24 +0900 >>> >>> Eli mentioned DWARF 2. The manual for GCC 4.8.4 says: >>> >>> -g >>> Produce debugging information in the operating system's native format >>> (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging >>> information. >>> >>> Later there is an option for specifying the version of DWARF, which >>> cautions that use of DWARF 4 "may require gdb 7 and >>> -fvar-tracking-assignments". I'll have to try that. > > AFAIU, -fvar-tracking-assignments is automatically turned on when > compiling an optimized program. Maybe it's better these days. In some cases, we really can't reconstruct values. Consider something like this: unsigned x = foo(); unsigned y = x / 2; If y == 4, we don't know whether x was 8 or 9. But that's not the case I've seen most. When debugging optimized code, though, I've run into far more annoying situations. Consider this code: void foo(void* context) { struct value* c = context; bar(c); } Say I'm broken into the program just before the call to bar and I want to inspect some field of c. I should be able to print c->field, right? Except GDB tells me that c is , even though context is right there and contains the same bits!