title: Conditions under which stepping into shared library should work in gdb?
body: <p>There are many questions related to specific errors why stepping into a shared library with gdb isn't working. None of them provide a systematic answer on how to confirm where the the cause is. This questions is about the ways to diagnose the setup.</p>
  
  <h2>Setup example</h2>
  
  <p><strong>main.c</strong></p>
  
  <pre><code>#include &lt;stdio.h&gt;
  #include "myshared.h"
  
  int main(void)
  {
      int a = 3;
      print_from_lib();
      return 0;
  }
  </code></pre>
  
  <p><strong>myshared.h</strong> </p>
  
  <pre><code>void print_from_lib();
  </code></pre>
  
  <p><strong>myshared.c</strong> </p>
  
  <pre><code>#include &lt;stdio.h&gt;
  
  void print_from_lib()
  {
      printf("Printed from shared library\n");
  }
  </code></pre>
  
  <p>Place all the files in the same directory.</p>
  
  <pre><code>export LIBRARY_PATH=$PWD:$LIBRARY_PATH
  export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH
  gcc -ggdb -c -Wall -Werror -fpic myshared.c -o myshared-ggdb.o
  gcc -ggdb -shared -o libmyshared-ggdb.so myshared-ggdb.o
  gcc -ggdb main.c -lmyshared-ggdb -o app-ggdb
  </code></pre>
  
  <h2>Getting the error</h2>
  
  <pre><code>$ gdb ./app-ggdb 
  GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git
  ...### GDB STARTING TEXT
  Reading symbols from app-ggdb...done.
  (gdb) break 7
  Breakpoint 1 at 0x78f: file main.c, line 7.
  (gdb) run
  Starting program: /home/user/share-lib-example/app-ggdb 
  
  Breakpoint 1, main () at main.c:7
  7       print_from_lib();
  (gdb) s
  Printed from shared library
  8       return 0;
  </code></pre>
  
  <p>gdb is not stepping inside of the function</p>
  
  <h2>Necessary but not sufficient checks</h2>
  
  <h3>Debug symbols in the binaries</h3>
  
  <pre><code>$ objdump --syms libmyshared-ggdb.so | grep debug
  0000000000000000 l    d  .debug_aranges 0000000000000000              .debug_aranges
  0000000000000000 l    d  .debug_info    0000000000000000              .debug_info
  0000000000000000 l    d  .debug_abbrev  0000000000000000              .debug_abbrev
  0000000000000000 l    d  .debug_line    0000000000000000              .debug_line
  0000000000000000 l    d  .debug_str     0000000000000000              .debug_str
  </code></pre>
  
  <h3>Symbols recognized by gdb</h3>
  
  <pre><code>$ gdb ./app-ggdb
  ...### GDB STARTING TEXT
  Reading symbols from app-ggdb...done.
  (gdb) break 7
  Breakpoint 1 at 0x78f: file main.c, line 7.
  (gdb) run
  Starting program: /home/user/share-lib-example/app-ggdb 
  
  Breakpoint 1, main () at main.c:7
  7       print_from_lib();
  (gdb)(gdb) info sharedlibrary
  From                To                  Syms Read   Shared Object Library
  0x00007ffff7dd7aa0  0x00007ffff7df55c0  Yes         /lib64/ld-linux-x86-64.so.2
  0x00007ffff7bd5580  0x00007ffff7bd5693  Yes         /home/user/share-lib-example/libmyshared-ggdb.so
  0x00007ffff782d9c0  0x00007ffff797ed43  Yes         /lib/x86_64-linux-gnu/libc.so.6
  </code></pre>
  
  <h3>Confirm .gdbinit isn't the cause</h3>
  
  <p><code>~/.gdbinit</code> contains commands automatically executed upon starting gdb. <a href="https://sourceware.org/gdb/onlinedocs/gdb/gdbinit-man.html" rel="nofollow noreferrer">ref.</a></p>
  
  <p>Running gdb with the <code>-nx</code> flags can exclude <code>.gdbinit</code> as the source of the problem. </p>
  
  <h1>Question</h1>
  
  <p>Am looking for suggestions to complete the list of <code>Necessary but not sufficient checks</code>.</p>
  
  <p><strong>Current issue [Update from  Mark Plotnick]</strong></p>
  
  <p>This step bug is reproducible on Ubuntu 17.04 amd64 with both a 64- and 32-bit executable and library.</p>
  
  <p>The bug isn't reproducible on Ubuntu 17.04 i386. (gcc 6.3.0-12ubuntu2, gdb 7.12.50 and 8.0, no .gdbinit.).</p>
  
  <p>Possibly relevant: gcc on 17.04 amd64 has been built (by Canonical) to generate pie executables by default.</p>
  
  <p><strong>Question</strong></p>
  
  <p>Can flags with which gcc was build with interfere with debugging? How can you identify if your gcc is the cause?</p>