title: Why is it that gdb "can't compute CFA" when using a separate debug symbols file?
body: <p>I'm trying to invoke gdb with a stripped executable and a separate debug symbols file, on a core dump generated from running the stripped executable.</p>
  
  <p>But when I use the separate debug symbols file, gdb is unable to give information on local variables for me.</p>
  
  <p>Here is a log showing entirely how I produce my 3 ELF files and the core file and then run them through gdb 3 times.</p>
  
  <ol>
  <li><p>First I just run gdb with the stripped executable and of course can't see any file names or line numbers, and can't inspect variables.</p></li>
  <li><p>Then I run gdb using the stripped executable and grabbing the debug symbols from the original unstripped executable.  This works pretty well but does give a disturbing and apparently unwarranted warning about the core and executable possibly mismatching.</p></li>
  <li><p>Finally I run gdb with the stripped executable and the separate debug file.  This still gives filenames and line numbers, but I can't inspect local variables and I get a "can't compute CFA for this frame" error.</p></li>
  </ol>
  
  <p>Here is the log:</p>
  
  <pre><code>2016-09-16 16:01:45 barry@somehost ~/proj/segfault/segfault
  $ cat segfault.c
  #include &lt;stdio.h&gt;
  int main(int argc, char **argv) {
      char *badpointer = (char *)0x2398723;
      printf("badpointer: %s\n", badpointer);
      return 0;
  }
  
  2016-09-16 16:03:31 barry@somehost ~/proj/segfault/segfault
  $ gcc -g -o segfault segfault.c
  
  2016-09-16 16:03:37 barry@somehost ~/proj/segfault/segfault
  $ objcopy --strip-debug segfault segfault.stripped
  
  2016-09-16 16:03:40 barry@somehost ~/proj/segfault/segfault
  $ objcopy --only-keep-debug segfault segfault.debug
  
  2016-09-16 16:03:43 barry@somehost ~/proj/segfault/segfault
  $ ./segfault.stripped
  Segmentation fault (core dumped)
  
  2016-09-16 16:03:48 barry@somehost ~/proj/segfault/segfault
  $ ll /tmp/core.segfault.stripp.11
  -rw------- 1 barry bsm-it 188416 2016-09-16 16:03 /tmp/core.segfault.stripp.11
  
  2016-09-16 16:03:51 barry@somehost ~/proj/segfault/segfault
  $ gdb ./segfault.stripped /tmp/core.segfault.stripp.11
  GNU gdb (GDB) Fedora (7.0.1-50.fc12)
  Copyright (C) 2009 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt;
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  For bug reporting instructions, please see:
  &lt;http://www.gnu.org/software/gdb/bugs/&gt;...
  Reading symbols from /home/barry/proj/segfault/segfault/segfault.stripped...(no debugging symbols found)...done.
  
  warning: core file may not match specified executable file.
  Missing separate debuginfo for
  Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a6/8dce9115a92508af92ac4ccac24b9f0cc34d71
  Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
  Loaded symbols for /lib64/libc.so.6
  Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
  Loaded symbols for /lib64/ld-linux-x86-64.so.2
  Core was generated by `./segfault.stripped'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  Missing separate debuginfos, use: debuginfo-install glibc-2.11.2-3.x86_64
  (gdb) bt
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  #2  0x00000000004004f4 in main ()
  (gdb) up
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  (gdb) up
  #2  0x00000000004004f4 in main ()
  (gdb) p argc
  No symbol table is loaded.  Use the "file" command.
  (gdb) q
  
  2016-09-16 16:04:19 barry@somehost ~/proj/segfault/segfault
  $ gdb -q -e ./segfault.stripped -s ./segfault -c /tmp/core.segfault.stripp.11
  Reading symbols from /home/barry/proj/segfault/segfault/segfault...done.
  
  warning: core file may not match specified executable file.
  Missing separate debuginfo for
  Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a6/8dce9115a92508af92ac4ccac24b9f0cc34d71
  Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
  Loaded symbols for /lib64/libc.so.6
  Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
  Loaded symbols for /lib64/ld-linux-x86-64.so.2
  Core was generated by `./segfault.stripped'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  Missing separate debuginfos, use: debuginfo-install glibc-2.11.2-3.x86_64
  (gdb) bt
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  #2  0x00000000004004f4 in main (argc=1, argv=0x7fffd1c0a728) at segfault.c:4
  (gdb) up
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  (gdb) up
  #2  0x00000000004004f4 in main (argc=1, argv=0x7fffd1c0a728) at segfault.c:4
  4       printf("badpointer: %s\n", badpointer);
  (gdb) p argc
  $1 = 1
  (gdb) q
  
  2016-09-16 16:04:39 barry@somehost ~/proj/segfault/segfault
  $ gdb -q -e ./segfault.stripped -s ./segfault.debug -c /tmp/core.segfault.stripp.11
  Reading symbols from /home/barry/proj/segfault/segfault/segfault.debug...done.
  
  warning: core file may not match specified executable file.
  Missing separate debuginfo for
  Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a6/8dce9115a92508af92ac4ccac24b9f0cc34d71
  Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
  Loaded symbols for /lib64/libc.so.6
  Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
  Loaded symbols for /lib64/ld-linux-x86-64.so.2
  Core was generated by `./segfault.stripped'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  Missing separate debuginfos, use: debuginfo-install glibc-2.11.2-3.x86_64
  (gdb) bt
  #0  0x00000035fec47cb7 in vfprintf () from /lib64/libc.so.6
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  #2  0x00000000004004f4 in main (argc=can't compute CFA for this frame
  ) at segfault.c:4
  (gdb) up
  #1  0x00000035fec4ec4a in printf () from /lib64/libc.so.6
  (gdb) up
  #2  0x00000000004004f4 in main (argc=can't compute CFA for this frame
  ) at segfault.c:4
  4       printf("badpointer: %s\n", badpointer);
  (gdb) p argc
  can't compute CFA for this frame
  (gdb) q
  </code></pre>
  
  <p>I have some questions about this:</p>
  
  <ol>
  <li>Why does it display the warning "warning: core file may not match specified executable file.", even though I'm using the exact same executable path as was used when the core dump was originally generated?</li>
  <li>Why does using the separate debug symbols (-s ./segfault.debug) result in the error "can't compute CFA for this frame" when attempting to inspect local variables?</li>
  </ol>
  
  <p>What is a CFA anyway?</p>
  
  <p>Am I using an incorrect method to product the debug symbol file?
  I confirmed that using "objcopy --strip-debug" gives the same result as "strip -g".
  Am I using the right options to feed the debug info into gdb?</p>
  
  <p>My intention is that the stripped executables will be installed on a binary-compatible production system and any core dumps generated due to segfaults can be copied back to the devel system where we can feed them into gdb with the debug info and analyse the crash position and stack variables.  But as a first step I'm trying to sort out the issues with using separate debug info files on the devel system.</p>
  
  <p>It seems that using a separate debug symbols file causes the "can't compute CFA for this frame" error, even when a core file is not used.</p>
  
  <p>My gcc version:</p>
  
  <pre><code>2016-09-16 16:07:39 barry@somehost ~/proj/segfault/segfault
  $ gcc -v
  Using built-in specs.
  Target: x86_64-redhat-linux
  Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
  Thread model: posix
  gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
  </code></pre>
  
  <p>I suspect that gdb might be looking for symbols related to the variables in the segfault.debug file when objcopy actually only put them in the segfault.stripped file.  If this is the case, perhaps some small adjustment to the options to objcopy could put those symbols in the place gdb is looking?</p>