call_graph.py without filtering done

Author: cirosantilli

c/hello_world.s

@@ -0,0 +1,26 @@
+	.file	"hello_world.c"
+	.section	.rodata
+.LC0:
+	.string	"hello world"
+	.text
+	.globl	main
+	.type	main, @function
+main:
+.LFB2:
+	.cfi_startproc
+	pushq	%rbp
+	.cfi_def_cfa_offset 16
+	.cfi_offset 6, -16
+	movq	%rsp, %rbp
+	.cfi_def_cfa_register 6
+	movl	$.LC0, %edi
+	call	puts
+	movl	$0, %eax
+	popq	%rbp
+	.cfi_def_cfa 7, 8
+	ret
+	.cfi_endproc
+.LFE2:
+	.size	main, .-main
+	.ident	"GCC: (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4"
+	.section	.note.GNU-stack,"",@progbits

c/implementations.md

@@ -16,6 +16,20 @@ FreeBSD moved to it in 2012: <http://unix.stackexchange.com/questions/49906/why-
 
 Sony PS4 (2013 Q4, FreeBSD based) moved to it while PS3 used GCC.
 
+The great advantages of this are:
+
+- better tooling than GNU: Python for scripting, CMake and Doxygen doc instead of `.exp`, Autotools and Texinfo
+- clearer design, since it was made 20 years later and it used what was learned
+- can be used as a library. This is a classic problem of bug CLI utilities: they were not designed to be used programmatically as a library, and it is hard to modify them to do so. GCC is pushing forward in that direction as well now.
+
+### Small Device C Compiler
+
+<https://en.wikipedia.org/wiki/Small_Device_C_Compiler>
+
+Targets mostly microcontrollers, which GCC does not target as well: <http://sourceforge.net/p/sdcc/mailman/message/31601719/>
+
+GPL.
+
 ### CompCert C compiler
 
 <http://compcert.inria.fr/compcert-C.html>

cflow.md

@@ -4,6 +4,8 @@ Make static call graphs.
 
 GNU.
 
+Not perfect nor ultra-powerful, but comes in handy when reading code.
+
 <https://en.wikipedia.org/wiki/GNU_cflow>
 
 <http://www.gnu.org/software/cflow/>

gcc/source-tree.md

@@ -207,3 +207,7 @@ Virtual table verification:
 - <https://sunglint.wordpress.com/2013/06/13/vtv/>
 
 Security feature.
+
+## Vocabulary
+
+- leaf function: function that does not call any other. Optimizations are possible for those functions, like not decrementing `rsp`: http://stackoverflow.com/questions/13201644/why-does-the-x86-64-gcc-function-prologue-allocate-less-stack-than-the-local-var and in x86-64 not saving function parameters passed as registers to stack.

gdb/README.md

@@ -2,6 +2,8 @@
 
 GNU debugger.
 
+Tested on 7.7.1 unless mentioned otherwise.
+
 1.  [Getting started](getting-started.md)
 1.  [Introduction](introduction.md)
 1.  [Invocation](invocation.md)
@@ -30,7 +32,8 @@ GNU debugger.
     1.  [read_var()](read_var.py)
     1.  [Command](command)
     1.  [argv-wrapper](argv-wrapper)
-    1.  [Call graph](call_graph_rbreak.py)
+    1.  [Call graph](call_graph.py)
+        1.  [Call graph rbreak](call_graph_rbreak.py)
     1.  [Continue until instruction](continue_instruction.py)
         1.  [Continue until return](continue_return.py)
     1.  [Break on return](break_return.py)

gdb/break_return.py

@@ -20,6 +20,7 @@ def invoke(self, arg, from_tty):
         while block:
             if block.function:
                 break
+            block = block.superblock
         start = block.start
         end = block.end
         arch = frame.architecture()

gdb/breakpoint.py

@@ -0,0 +1,29 @@
+"""
+## Brekapoint
+
+Create breakpoints from the python API.
+
+TODO: create a breakpoint with the python API without ouputting anyting to stdout?
+"""
+
+gdb.execute('file big_function.out', to_string=True)
+
+# Noisy.
+gdb.Breakpoint('main')
+gdb.Breakpoint('main', internal=True)
+
+# Noisy.
+class Breakpoint0(gdb.Breakpoint):
+    def stop (self):
+        """
+        Action to take when the breakpoint is reached.
+        """
+        gdb.write('0\n')
+        # Continue automatically.
+        return False
+        # Actually stop.
+        return True
+Breakpoint0('main')
+
+gdb.execute('run')
+gdb.execute('continue')

gdb/call_graph.py

@@ -12,12 +12,11 @@
 """
 
 gdb.execute('file call_graph_py.out', to_string=True)
-# rbreak before start to ignore dynamically linked stdlib functions.
-gdb.execute('set confirm off')
 gdb.execute('start', to_string=True)
 depth_string = 4 * ' '
 thread = gdb.inferiors()[0].threads()[0]
-while thread.is_valid():
+disassembled_functions = set()
+while True:
     frame = gdb.selected_frame()
     symtab = frame.find_sal().symtab
 
@@ -30,7 +29,6 @@
     # Not present for files without debug symbols.
     source_path = '???'
     if symtab:
-        #source_path = symtab.fullname()
         source_path = symtab.filename
 
     # Not present for files without debug symbols.
@@ -46,22 +44,32 @@
             if symbol.is_argument:
                 args += '{} = {}, '.format(symbol.name, symbol.value(frame))
 
-        # Mark new breakpoints.
-        while block:
-            if block.function:
-                break
+        # Put a breakpoint on the address of every funtion called from this function.
+        # Only do that the first time we enter a function (TODO implement.)
         start = block.start
-        end = block.end
-        arch = frame.architecture()
-        pc = gdb.selected_frame().pc()
-        instructions = arch.disassemble(start, end - 1)
-        for instruction in instructions:
-            print('{:x} {}'.format(instruction['addr'], instruction['asm']))
+        if not start in disassembled_functions:
+            disassembled_functions.add(start)
+            end = block.end
+            arch = frame.architecture()
+            pc = gdb.selected_frame().pc()
+            instructions = arch.disassemble(start, end - 1)
+            for instruction in instructions:
+                # This is UGLY. I wish there was a disassembly Python interface to GDB,
+                # like https://github.com/aquynh/capstone which allows me to extract
+                # the opcode without parsing.
+                if instruction['asm'].split()[0] == 'callq':
+                    gdb.Breakpoint('*{}'.format(instruction['addr']), internal=True)
 
     print('{}{} : {} : {}'.format(
         stack_depth * depth_string,
         source_path,
         frame.name(),
         args
     ))
+    # We are at the call instruction.
     gdb.execute('continue', to_string=True)
+    if thread.is_valid():
+        # We are at the first instruction of the called function.
+        gdb.execute('stepi', to_string=True)
+    else:
+        break

gdb/call_graph_rbreak.py

@@ -7,14 +7,27 @@
 
 - http://stackoverflow.com/questions/9549693/gdb-list-of-all-function-calls-made-in-an-application
 - http://stackoverflow.com/questions/311948/make-gdb-print-control-flow-of-functions-as-they-are-called
+
+What happens on the output:
+
+-   First line is:
+
+        ../csu/init-first.c : _init : argc = 1, argv = 0x7fffffffd728, envp = 0x7fffffffd738
+
+    It actually does get called before the `_start`:
+    http://stackoverflow.com/questions/31379422/why-is-init-from-glibcs-csu-init-first-c-called-before-start-even-if-start-i
+
+    I think it has a level deeper than one because the callees are not broke on:
+    they are not part of the executable.
 """
 
-gdb.execute('file cc1', to_string=True)
-gdb.execute('rbreak .', to_string=True)
-gdb.execute('set args hello_world.c', to_string=True)
-# rbreak before start to ignore dynamically linked stdlib functions.
+gdb.execute('file ./call_graph_py.out', to_string=True)
 gdb.execute('set confirm off')
-gdb.execute('start', to_string=True)
+# rbreak before run to ignore dynamically linked stdlib functions which take too long.
+# If we do it before, we would also go into stdlib functions, which is often what we don't want,
+# since we already understand them.
+gdb.execute('rbreak .', to_string=True)
+gdb.execute('run', to_string=True)
 depth_string = 4 * ' '
 thread = gdb.inferiors()[0].threads()[0]
 while thread.is_valid():

gdb/commands.md

@@ -87,6 +87,8 @@ The program will run until it reaches:
 
 Like run, but also add a temporary (deleted once hit) breakpoint at `main` and stop there.
 
+`main` this is not the actual executable entry point, see also: <http://stackoverflow.com/questions/10483544/stopping-at-the-first-machine-code-instruction-in-gdb>
+
 ### q
 
 ### quit
@@ -268,6 +270,32 @@ Set breakpoint at address:
 
     b *0x400440
 
+If you set a breakpoint in the middle of an instruction, segfault. E.g., supposing `0x400440` is 2 bytes long, then:
+
+    b *0x400441
+    c
+    c
+
+may segfault. TODO why? Linked to hardware breakpoints I imagine.
+
+`break function` does not break on the very first instruction of the function, but rather further after the prologue: <http://stackoverflow.com/questions/25545994/how-does-gdb-determine-function-entry-points> GDB guesses prologues even without debug information. TODO can debug information contain prologue information?
+
+#### Dynamically loaded library breakpoints
+
+When you do:
+
+    break printf
+
+before running the program, what happens depends on the value of:
+
+    show breakpoint pending
+
+which can be set with:
+
+    set breakpoint pending on|off|auto
+
+The default is auto, which is not `auto`, but rather asks for confirmation...
+
 ### watch
 
 ### rwatch
@@ -304,6 +332,8 @@ Break at all function calls:
 
 If you do this after running `start`, it will add hundreds of breaks and take a noticeable amount (e.g. 30 seconds) of time for a hello world because of the dynamic library functions. If done before `start`, those will not be seen.
 
+This will also pick up the execution of the loader which the kernel points to before `_start`: <http://stackoverflow.com/questions/31379422/why-is-init-from-glibcs-csu-init-first-c-called-before-start-even-if-start-i/31387656#31387656>
+
 ### dis
 
 ### disable
@@ -742,6 +772,13 @@ Current line every time the debugger stops:
 
     set disassemble-next-line on
 
+Without debug information in an unstripped ELF:
+
+- uses the `st_size` of the symbol to dissemble to determine where to stop
+- without arguments, finds the current function by searching for the closest symbol that contains `$pc` and has `st_size` set
+
+Being a `STT_FUNC` does not seem required.
+
 ### x
 
 Examine 4 bytes of memory:

gdb/disas.py

@@ -1,15 +1,23 @@
 """
 ## disas
 
-Python implementation of disas
+Python implementation of the `disas` command.
 """
 
 def disas():
     frame = gdb.selected_frame()
+    # TODO: make this work for files without debugging info.
+    # block() is only available with debug information.
+    #
+    # What we need is to use symbol information instead.
+    # ELF symboltable symbols have the initial address
+    # and the size attributes, so that should be enough.
     block = frame.block()
+    # Find the current function if in an inner block.
     while block:
         if block.function:
             break
+        block = block.superblock
     start = block.start
     end = block.end
     arch = frame.architecture()
@@ -18,8 +26,12 @@ def disas():
     for instruction in instructions:
         print('{:x} {}'.format(instruction['addr'], instruction['asm']))
 
-gdb.execute('file if_else.out', to_string=True)
+gdb.execute('file disas_py.out', to_string=True)
 gdb.execute('start', to_string=True)
 disas()
+
+# Test from the inner block.
+gdb.execute('break 9', to_string=True)
+gdb.execute('continue', to_string=True)
 print()
-gdb.execute('disas')
+disas()

gdb/disas_py.c

@@ -0,0 +1,15 @@
+#include <stdio.h>
+#include <time.h>
+
+int main() {
+    int i;
+    i  = time(NULL);
+    /* This should generate an inner block. */
+    {
+        int i;
+        i = time(NULL);
+        printf("%d\n", i);
+    }
+    printf("%d\n", i);
+    return 0;
+}

gdb/hello_world.c

@@ -0,0 +1,7 @@
+#include <stdio.h>
+#include <stdlib.h>
+
+int main() {
+    puts("hello world");
+    return EXIT_SUCCESS;
+}

gdb/internals.md

@@ -10,3 +10,7 @@ Hardware vs software breakpoints: <http://stackoverflow.com/questions/8878716/wh
 ## Vocabulary
 
 - `sal`: symtable and line. Both are often passed around together. TODO why.
+
+## Source tree
+
+- `cli/cli-cmds.c`: defines the built-in commands. Good place to start probing. Not *all* commands are there however. Grep for strings, e.g. `"break"`.

gdb/python-interface.md

@@ -69,6 +69,10 @@ Exit with Ctrl + D.
 
 ## Bibliography
 
-2008 tutorial: <https://sourceware.org/gdb/wiki/PythonGdbTutorial>
+- `help gdb` from the python shell. Great way to see what the API contains. Then read the `.texi` docs for the details.
 
-Library that uses it a lot: <https://github.com/longld/peda/>
+- <https://sourceware.org/gdb/wiki/PythonGdbTutorial> 2008 tutorial by the API author. Somewhat outdated.
+
+- <https://github.com/longld/peda/> famous library that uses it a lot
+
+- <https://github.com/stephenbradshaw/pygdbdis/blob/master/pygdbdis.py> small library that also uses it

glibc/crt1.md

@@ -70,3 +70,13 @@ Come from `libgcc/crtstuff.c`.
 ## Scrt1
 
 <http://stackoverflow.com/questions/16436035/whats-the-usage-of-mcrt1-o-and-scrt1-o>
+
+## init-first
+
+TODO. This actually seems to be the actual initial code that is run, *not* `_start`, even though `_start` is set at the ELF header as the entry point. What is going on?
+
+Just try to do `b _init` on `gdb`.
+
+## Bibliography
+
+- <http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html>