What does value optimized out mean in gdb

Question

gdb  n 134   a   b   c   0xdeadbeef     uint32 t length    initval   gdb  n  gdb  p a  30    lt value optimized out gt   gdb  p b  31    lt value optimized out gt   gdb  p c  32   3735928563   How can gdb optimize out my value

User · Answer

From https   idlebox net 2010 apidocs gdb-7 0 zip gdb 9 html  The values of arguments that were not saved in their stack frames are shown as  value optimized out    Im guessing you compiled with -O somevalue  and are accessing variables a b c in a function where optimization has occurred

User · Answer

It means you compiled with e g  gcc -O3 and the gcc optimiser found that some of your variables were redundant in some way that allowed them to be optimised away  In this particular case you appear to have three variables a  b  c with the same value and presumably they can all be aliassed to a single variable  Compile with optimisation disabled  e g  gcc -O0  if you want to see such variables  this is generally a good idea for debug builds in any case

User · Answer

Just run  export COPTS  -g -O0    and rebuild your code  After rebuild  debug it using gdb  You ll not see such error  Thanks

User · Answer

Minimal runnable example with disassembly analysis  As usual  I like to see some disassembly to get a better understanding of what is going on   In this case  the insight we obtain is that if a variable is optimized to be stored only in a register rather than the stack  and then the register it was in gets overwritten  then it shows as  lt optimized out gt  as mentioned by R    Of course  this can only happen if the variable in question is not needed anymore  otherwise the program would lose its value  Therefore it tends to happen that at the start of the function you can see the variable value  but then at the end it becomes  lt optimized out gt    One typical case which we often are interested in of this is that of the function arguments themselves  since these are    always defined at the start of the function may not get used towards the end of the function as more intermediate values are calculated  tend to get overwritten by further function subcalls which must setup the exact same registers to satisfy the calling convention    This understanding actually has a concrete application  when using reverse debugging  you might be able to recover the value of variables of interest simply by stepping back to their last point of usage  How do I view the value of an  lt optimized out gt  variable in C     main c   include  lt stdio h gt   int   attribute    noinline   f3 int i        return i   1     int   attribute    noinline   f2 int i        return f3 i    1     int   attribute    noinline   f1 int i        int j   1  k   2  l   3      i    1      j    f2 i       k    f2 j       l    f2 k       return l     int main int argc  char  argv          printf   d n   f1 argc        return 0      Compile and run   gcc -ggdb3 -O3 -std c99 -Wall -Wextra -pedantic -o main out main c gdb -q -nh main out   Then inside GDB  we have the following session   Breakpoint 1  f1  i 1  at main c 13 13          i    1   gdb  disas Dump of assembler code for function f1    gt  0x00005555555546c0  lt  0 gt       add     0x1  edi    0x00005555555546c3  lt  3 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546c8  lt  8 gt       lea    0x1  rax   edi    0x00005555555546cb  lt  11 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d0  lt  16 gt      lea    0x2  rax   edi    0x00005555555546d3  lt  19 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d8  lt  24 gt      add     0x3  eax    0x00005555555546db  lt  27 gt      retq    End of assembler dump   gdb  p i  1   1  gdb  p j  2   1  gdb  n 14          j    f2 i    gdb  disas Dump of assembler code for function f1     0x00005555555546c0  lt  0 gt       add     0x1  edi   gt  0x00005555555546c3  lt  3 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546c8  lt  8 gt       lea    0x1  rax   edi    0x00005555555546cb  lt  11 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d0  lt  16 gt      lea    0x2  rax   edi    0x00005555555546d3  lt  19 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d8  lt  24 gt      add     0x3  eax    0x00005555555546db  lt  27 gt      retq    End of assembler dump   gdb  p i  3   2  gdb  p j  4   1  gdb  n 15          k    f2 j    gdb  disas Dump of assembler code for function f1     0x00005555555546c0  lt  0 gt       add     0x1  edi    0x00005555555546c3  lt  3 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546c8  lt  8 gt       lea    0x1  rax   edi   gt  0x00005555555546cb  lt  11 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d0  lt  16 gt      lea    0x2  rax   edi    0x00005555555546d3  lt  19 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d8  lt  24 gt      add     0x3  eax    0x00005555555546db  lt  27 gt      retq    End of assembler dump   gdb  p i  5    lt optimized out gt   gdb  p j  6   5  gdb  n 16          l    f2 k    gdb  disas Dump of assembler code for function f1     0x00005555555546c0  lt  0 gt       add     0x1  edi    0x00005555555546c3  lt  3 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546c8  lt  8 gt       lea    0x1  rax   edi    0x00005555555546cb  lt  11 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d0  lt  16 gt      lea    0x2  rax   edi   gt  0x00005555555546d3  lt  19 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d8  lt  24 gt      add     0x3  eax    0x00005555555546db  lt  27 gt      retq    End of assembler dump   gdb  p i  7    lt optimized out gt   gdb  p j  8    lt optimized out gt    To understand what is going on  remember from the x86 Linux calling convention  What are the calling conventions for UNIX  amp  Linux system calls on i386 and x86-64 you should know that    RDI contains the first argument RDI can get destroyed in function calls RAX contains the return value   From this we deduce that   add     0x1  edi   corresponds to the   i    1    since i is the first argument of f1  and therefore stored in RDI   Now  while we were at both   i    1  j    f2 i     the value of RDI hadn t been modified  and therefore GDB could just query it at anytime in those lines   However  as soon as the f2 call is made    the value of i is not needed anymore in the program lea    0x1  rax   edi does EDI   j   RAX   1  which both    initializes j   1 sets up the first argument of the next f2 call to RDI   j    Therefore  when the following line is reached   k    f2 j     both of the following instructions have may have modified RDI  which is the only place i was being stored  f2 may use it as a scratch register  and lea definitely set it to RAX   1       0x00005555555546c3  lt  3 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546c8  lt  8 gt       lea    0x1  rax   edi   and so RDI does not contain the value of i anymore  In fact  the value of i was completely lost  Therefore the only possible outcome is    3    lt optimized out gt    A similar thing happens to the value of j  although j only becomes unnecessary one line later afer the call to k    f2 j     Thinking about j also gives us some insight on how smart GDB is  Notably  at i    1   the value of j had not yet materialized in any register or memory address  and GDB must have known it based solely on debug information metadata   -O0 analysis  If we use -O0 instead of -O3 for compilation   gcc -ggdb3 -O0 -std c99 -Wall -Wextra -pedantic -o main out main c   then the disassembly would look like   11      int   attribute    noinline   f1 int i      gt  0x0000555555554673  lt  0 gt       55      push    rbp    0x0000555555554674  lt  1 gt       48 89 e5        mov     rsp  rbp    0x0000555555554677  lt  4 gt       48 83 ec 18     sub     0x18  rsp    0x000055555555467b  lt  8 gt       89 7d ec        mov     edi -0x14  rbp   12          int j   1  k   2  l   3     0x000055555555467e  lt  11 gt      c7 45 f4 01 00 00 00    movl    0x1 -0xc  rbp     0x0000555555554685  lt  18 gt      c7 45 f8 02 00 00 00    movl    0x2 -0x8  rbp     0x000055555555468c  lt  25 gt      c7 45 fc 03 00 00 00    movl    0x3 -0x4  rbp   13          i    1     0x0000555555554693  lt  32 gt      83 45 ec 01     addl    0x1 -0x14  rbp   14          j    f2 i      0x0000555555554697  lt  36 gt      8b 45 ec        mov    -0x14  rbp   eax    0x000055555555469a  lt  39 gt      89 c7   mov     eax  edi    0x000055555555469c  lt  41 gt      e8 b8 ff ff ff  callq  0x555555554659  lt f2 gt     0x00005555555546a1  lt  46 gt      01 45 f4        add     eax -0xc  rbp   15          k    f2 j      0x00005555555546a4  lt  49 gt      8b 45 f4        mov    -0xc  rbp   eax    0x00005555555546a7  lt  52 gt      89 c7   mov     eax  edi    0x00005555555546a9  lt  54 gt      e8 ab ff ff ff  callq  0x555555554659  lt f2 gt     0x00005555555546ae  lt  59 gt      01 45 f8        add     eax -0x8  rbp   16          l    f2 k      0x00005555555546b1  lt  62 gt      8b 45 f8        mov    -0x8  rbp   eax    0x00005555555546b4  lt  65 gt      89 c7   mov     eax  edi    0x00005555555546b6  lt  67 gt      e8 9e ff ff ff  callq  0x555555554659  lt f2 gt     0x00005555555546bb  lt  72 gt      01 45 fc        add     eax -0x4  rbp   17          return l     0x00005555555546be  lt  75 gt      8b 45 fc        mov    -0x4  rbp   eax  18           0x00005555555546c1  lt  78 gt      c9      leaveq     0x00005555555546c2  lt  79 gt      c3      retq    From this horrendous disassembly  we see that the value of RDI is moved to the stack at the very start of program execution at   mov     edi -0x14  rbp    and it then gets retrieved from memory into registers whenever needed  e g  at   14          j    f2 i      0x0000555555554697  lt  36 gt      8b 45 ec        mov    -0x14  rbp   eax    0x000055555555469a  lt  39 gt      89 c7   mov     eax  edi    0x000055555555469c  lt  41 gt      e8 b8 ff ff ff  callq  0x555555554659  lt f2 gt     0x00005555555546a1  lt  46 gt      01 45 f4        add     eax -0xc  rbp    The same basically happens to j which gets immediately pushed to the stack when when it is initialized      0x000055555555467e  lt  11 gt      c7 45 f4 01 00 00 00    movl    0x1 -0xc  rbp    Therefore  it is easy for GDB to find the values of those variables at any time  they are always present in memory   This also gives us some insight on why it is not possible to avoid  lt optimized out gt  in optimized code  since the number of registers is limited  the only way to do that would be to actually push unneeded registers to memory  which would partly defeat the benefit of -O3   Extend the lifetime of i  If we edited f1 to return l   i as in   int   attribute    noinline   f1 int i        int j   1  k   2  l   3      i    1      j    f2 i       k    f2 j       l    f2 k       return l   i      then we observe that this effectively extends the visibility of i until the end of the function   This is because with this we force GCC to use an extra variable to keep i around until the end      0x00005555555546c0  lt  0 gt       lea    0x1  rdi   edx    0x00005555555546c3  lt  3 gt       mov     edx  edi    0x00005555555546c5  lt  5 gt       callq  0x5555555546b0  lt f2 gt     0x00005555555546ca  lt  10 gt      lea    0x1  rax   edi    0x00005555555546cd  lt  13 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546d2  lt  18 gt      lea    0x2  rax   edi    0x00005555555546d5  lt  21 gt      callq  0x5555555546b0  lt f2 gt     0x00005555555546da  lt  26 gt      lea    0x3  rdx  rax 1   eax    0x00005555555546de  lt  30 gt      retq   which the compiler does by storing i    i in RDX at the very first instruction   Tested in Ubuntu 18 04  GCC 7 4 0  GDB 8 1 0

User · Answer

You need to turn off the compiler optimisation   If you are interested in a particular variable in gdb  you can delare the variable as  volatile  and recompile the code  This will make the compiler turn off compiler optimization for that variable   volatile int quantity   0

User · Answer

It didn t  Your compiler did  but there s still a debug symbol for the original variable name

[gdb] What does <value optimized out> mean in gdb?

Examples related to gdb