{"id":2842,"date":"2019-08-21T20:17:17","date_gmt":"2019-08-21T20:17:17","guid":{"rendered":"https:\/\/nenadnoveljic.com\/blog\/?p=2842"},"modified":"2019-08-21T20:21:24","modified_gmt":"2019-08-21T20:21:24","slug":"tracking-arguments-gdb","status":"publish","type":"post","link":"https:\/\/nenadnoveljic.com\/blog\/tracking-arguments-gdb\/","title":{"rendered":"Tracking Arguments with gdb"},"content":{"rendered":"

DTrace<\/h1>\n

Being able to track function arguments is essential for in-depth troubleshooting and researching software internals. DTrace makes this extremely easy, because all of the arguments are exposed through the variables arg0, arg1, arg2,<\/i> etc. in the function entry probe.<\/p>\n

I’m going to use the following C program from [Yurichev 2013]<\/a> for demonstration purposes:<\/p>\n

#include <stdio.h>\n\nvoid f1(int a1, int a2, int a3, int a4, int a5, int a6, int a7)\n{\n  printf (\"%d %d %d %d %d %d %d\\n\", a1, a2, a3, a4, a5, a6, a7);\n};\n\nint main()\n{\n  f1(1,2,3,4,5,6,7);\n};<\/code><\/pre>\n
I compiled it with gcc:<\/p>\n
gcc f1.c -o f1<\/code><\/pre>\n
As you can see, capturing arguments is really trivial with DTrace:<\/p>\n
sudo -u root \/usr\/sbin\/dtrace -qn 'pid$target::f1:entry{ printf(\"%d %d %d %d %d %d %d \\n\",arg0,arg1,arg2,arg3,arg4,arg5,arg6);}' -p PID\n1 2 3 4 5 6 7 <\/code><\/pre>\n
gdb is an alternative where DTrace isn’t available. However, the complexity increases when the debugging information is stripped, which is rather common with proprietary software. To show how to track arguments under such circumstances, I’m going to disassemble the compiled C program and observe how the arguments get passed around. Dennis Yurichev explained this reverse engineering technique in [Yurichev 2013]<\/a>.<\/p>\n
Integers<\/h1>\n
Generally, the parameters can be passed in two ways: via CPU registers and stack. Which registers are used is precisely defined by calling conventions specific to CPU architecture and OS. The x86 calling conventions are, for instance, described in [Wikipedia]<\/a>.The integers are passed via rdi, rsi, rdx, rcx, r8<\/i> and r9<\/i> registers on Linux and Solaris. Since only 6 parameters can be passed through these registers, the rest must be passed via stack. Disassembled main<\/i> function indeed shows how these first 6 argument values are moved to the registers prior to calling the f1<\/i> function:<\/p>\n
0x0000000000400fc4 <+0>:     push   %rbp\n0x0000000000400fc5 <+1>:     mov    %rsp,%rbp\n0x0000000000400fc8 <+4>:     sub    $0x8,%rsp\n0x0000000000400fcc <+8>:     pushq  $0x7\n0x0000000000400fce <+10>:    mov    $0x6,%r9d<\/span>\n0x0000000000400fd4 <+16>:    mov    $0x5,%r8d<\/span>\n0x0000000000400fda <+22>:    mov    $0x4,%ecx<\/span>\n0x0000000000400fdf <+27>:    mov    $0x3,%edx<\/span>\n0x0000000000400fe4 <+32>:    mov    $0x2,%esi<\/span>\n0x0000000000400fe9 <+37>:    mov    $0x1,%edi<\/span>\n0x0000000000400fee <+42>:    callq  0x400f72 \n0x0000000000400ff3 <+47>:    add    $0x10,%rsp\n0x0000000000400ff7 <+51>:    mov    $0x0,%eax\n0x0000000000400ffc <+56>:    leaveq \n0x0000000000400ffd <+57>:    retq   <\/code><\/pre>\n
gdb f1 <<< \"disas main\"<\/code><\/pre>\n
Since the integer arguments fit into 32 bits they are passed via edi, esi, edx, ecx, r8d<\/i> and r9d<\/i> registers. All of those 32-bit registers exist for efficiently accessing the least significant 32 bits of the 64-bit registers rdi, rsi, rdx, rcx, r8<\/i> and r9<\/i>, respectively.<\/p>\n
Thus, we can display the first 6 integer arguments by printing the register values when the function f1<\/i> is entered:<\/p>\n
b f1 \nc\nThread 2 hit Breakpoint 1, 0x0000000000400f76 in f1 ()\n\nprintf \"%d, %d, %d, %d, %d, %d \\n\", $edi, $esi, $edx, $ecx, $r8d, $r9d \n1, 2, 3, 4, 5, 6 <\/code><\/pre>\n
Stack<\/h1>\n
The 7th argument was pushed onto the stack prior to calling f1<\/i>:<\/p>\n
0x0000000000400fcc <+8>:     pushq  $0x7<\/code><\/pre>\n
Before retrieving the argument from the stack within f1<\/i>, we have to know exactly how many values are on the stack in front of the argument.<\/p>\n
But first, let’s take a closer look at the addresses. Below is the disassembled f1<\/i> function:<\/p>\n
gdb f1 <<< \"disas f1\"\n\n0x0000000000400f72<\/span> <+0>:     push   %rbp\n0x0000000000400f73 <+1>:     mov    %rsp,%rbp\n0x0000000000400f76<\/span> <+4>:     sub    $0x20,%rsp\n0x0000000000400f7a <+8>:     mov    %edi,%eax\n...<\/code><\/pre>\n
It’s worth noting that the function begins at the address 0x400f72<\/span>, but the breakpoint was set a couple of lines farther – at the address 0x400f76<\/span>:<\/p>\n
info b\nNum     Type           Disp Enb Address            What\n1       breakpoint     keep y   0x0000000000400f76<\/span> <f1+4>\n<\/f1+4><\/code><\/pre>\n
The code fragment inbetween is the function prologue, which first saves the caller’s frame pointer (stored in rbp<\/i>) on the stack and then creates callee’s frame by copying rbp<\/i> into the stack pointer register rsp<\/i>. Gustavo Duarte described this mechanism in detail in [Duarte 2014]<\/a>. Consequently, argument’s position on the stack relative to the stack pointer rsp<\/i> will change after the prologue execution.<\/p>\n
The following picture illustrates the stack before and after the prologue execution:<\/p>\n\n\n
\"\"<\/figure>\n\n\n
When retrieving the argument, we have to exactly know where the program stopped. In our example gdb detected the prologue and set the breakpoint at its end. But this mechanism isn’t reliable, because gdb doesn’t always recognize the prologue. This can happen, for example, when some compiler optimizations are employed. Fortunately, we can enforce a break point at the function entry, i.e. before the prologue, by specifying *<\/i> before the function name:<\/p>\n
b *f1\nBreakpoint 1 at 0x400f72<\/span><\/code><\/pre>\n
Now the 7th argument can be safely retrieved from the second location on the stack:<\/p>\n
x\/d $rsp+8\n0x7fffbffff930: 7<\/code><\/pre>\n
Floating point<\/h1>\n
The floating point arguments are passed via xmm0 – xmm7<\/i> registers.<\/p>\n
We can easily demonstrate this by converting the first argument to floating point:<\/p>\n
#include <stdio.h>\n\nvoid f1(float<\/span> a1, int a2, int a3, int a4, int a5, int a6, int a7)\n{\n  printf (\"%f %d %d %d %d %d %d\\n\", a1, a2, a3, a4, a5, a6, a7);\n};\n\nint main()\n{\n  f1(1,2,3,4,5,6,7);\n};<\/code><\/pre>\n
The floating point value is stored as a constant on the location 0x400d64<\/span> and loaded into the xmm0<\/i> register.<\/p>\n
\n0x0000000000400fce <+0>:     push   %rbp\n0x0000000000400fcf <+1>:     mov    %rsp,%rbp\n0x0000000000400fd2 <+4>:     mov    $0x7,%r9d\n0x0000000000400fd8 <+10>:    mov    $0x6,%r8d\n0x0000000000400fde <+16>:    mov    $0x5,%ecx\n0x0000000000400fe3 <+21>:    mov    $0x4,%edx\n0x0000000000400fe8 <+26>:    mov    $0x3,%esi\n0x0000000000400fed <+31>:    mov    $0x2,%edi\n0x0000000000400ff2 <+36>:    movss  -0x296(%rip),%xmm0        # 0x400d64<\/span>\n0x0000000000400ffa <+44>:    callq  0x400f72 \n0x0000000000400fff <+49>:    mov    $0x0,%eax\n0x0000000000401004 <+54>:    pop    %rbp\n0x0000000000401005 <+55>:    retq   \n   \nx\/f 0x400d64\n0x400d64:       1<\/span>\n<\/code><\/pre>\n
Expectedly, there aren’t any parameters passed via stack anymore as the other 6 parameters fit into the r*<\/i> registers.<\/p>\n
The value of the first argument can be retrieved on the f1<\/i> entry point as follows:<\/p>\n
p $xmm0\n$1 = {v4_float = {1<\/span>, 0, 0, 0}, v2_double = {5.2635442471208903e-315, 0}, v16_int8 = {0, 0, -128, 63, 0 }, v8_int16 = {0, 16256, 0, 0, 0, 0, 0, 0}, v4_int32 = {1065353216, 0, 0, 0}, \n  v2_int64 = {1065353216, 0}, uint128 = 1065353216}<\/code><\/pre>\n
Pointers<\/h1>\n
To demonstrate how to retrieve the variables passed by reference, I modified the C program to pass a pointer to a string as the first argument. Additionally, I added the 8th argument – also a pointer to a string – in order to show how to dereference pointers when passed in both ways: via register and via stack.<\/p>\n
#include <stdio.h>\n#include <stdint.h>\n\nvoid f1(char* a1<\/span>, int a2, int a3, int a4, int a5, int a6, int a7, char* a8<\/span>)\n{\n  printf (\"%s %d %d %d %d %d %d %s\\n\", a1, a2, a3, a4, a5, a6, a7, a8);\n};\n\nint main()\n{\n  uint64_t dummy = 1 ;\n  char *str1 = \"String 1\";\n  char *str2 = \"String 8\";\n  f1(str1,2,3,4,5,6,7,str2);\n};<\/code><\/pre>\n
We can see that for pointers the whole 64-bit rdi<\/i> register is being used – as opposed to the least significant 32 bits referenced via edi<\/i> when dealing with integers.<\/p>\n
0x0000000000400fde <+0>:     push   %rbp\n0x0000000000400fdf <+1>:     mov    %rsp,%rbp\n0x0000000000400fe2 <+4>:     sub    $0x10,%rsp\n0x0000000000400fe6 <+8>:     movq   $0x400d65,-0x8(%rbp)<\/span>\n0x0000000000400fee <+16>:    movq   $0x400d6e,-0x10(%rbp)<\/span>\n0x0000000000400ff6 <+24>:    mov    -0x8(%rbp),%rax<\/span>\n0x0000000000400ffa <+28>:    pushq  -0x10(%rbp)<\/span>\n0x0000000000400ffd <+31>:    pushq  $0x7\n0x0000000000400fff <+33>:    mov    $0x6,%r9d\n0x0000000000401005 <+39>:    mov    $0x5,%r8d\n0x000000000040100b <+45>:    mov    $0x4,%ecx\n0x0000000000401010 <+50>:    mov    $0x3,%edx\n0x0000000000401015 <+55>:    mov    $0x2,%esi\n0x000000000040101a <+60>:    mov    %rax,%rdi<\/span>\n0x000000000040101d <+63>:    callq  0x400f82 \n0x0000000000401022 <+68>:    add    $0x10,%rsp\n0x0000000000401026 <+72>:    mov    $0x0,%eax\n0x000000000040102b <+77>:    leaveq \n0x000000000040102c <+78>:    retq   <\/code><\/pre>\n
Both string constants are stored at fix addresses:<\/p>\n
(gdb) x\/s 0x400d65\n0x400d65:       \"String 1\"<\/span>\n(gdb) x\/s 0x400d6e\n0x400d6e:       \"String 8\"<\/span><\/code><\/pre>\n
First, I’ll run the program and stop the execution after entering f1<\/i>:<\/p>\n
b *f1\nBreakpoint 1 at 0x400f82: file f1.c, line 5.\nr<\/code><\/pre>\n
The pointer to the first argument is passed via the rdi<\/i> register, which we can simply dereference as follows:<\/p>\n
x\/s $rdi\n0x400d65:       \"String 1\"<\/span><\/code><\/pre>\n
The pointer to the string passed as the 8th argument, which is the second argument passed via stack, is stored on the third stack location. Therefore, it can be dereferenced as follows:<\/p>\n
x\/s *(uint64_t *)($rsp+8+8)\n0x400d6e:       \"String 8\"<\/span><\/code><\/pre>\n
A side note: I had to include stdint.h<\/i> header file and declare a uint64_t<\/i> variable, just to be able to use uint64_t<\/i> type when dereferencing the pointer in gdb. For the same reason, I additionally compiled the program with the -g<\/i> option to include the symbol table:<\/p>\n
gcc -g f1.c -o f1<\/code><\/pre>\n
Tracing Oracle memory allocations<\/h1>\n
Finally, it’s time to do something useful, like, for example, trace Oracle memory allocations. These are performed within the Oracle C functions kghalf, kghalo<\/i> and kghalp<\/i>.<\/p>\n
Tanel Poder and Stefan Koehler have already written DTrace scripts for tracing their execution: trace_kghal.sh<\/a> and dtrace_kghal_pga_code<\/a>, respectively.<\/p>\n
By looking into their DTrace scripts, we can identify the following information of interest:<\/p>\n
By the way, I’m using Franck Pachot’s one-liner for disassembling functions provided in [Pachot 2017]<\/a>:<\/p>\n