llvm.org GIT mirror llvm / 4c2b0d4
Merging r155895: ------------------------------------------------------------------------ r155895 | eliben | 2012-04-30 23:15:40 -0700 (Mon, 30 Apr 2012) | 4 lines Removed examples of stack frame inspection which no longer work for old JIT. Added an example of MCJIT-based debugging. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155901 91177308-0d34-0410-b5e6-96231b3b80d8 Bill Wendling 8 years ago
1 changed file(s) with 141 addition(s) and 110 deletion(s). Raw diff Collapse all Expand all
77
88
99
10

Debugging JITed Code With GDB

10

Debugging JIT-ed Code With GDB

1111
12
  • Example usage
  • 1312
  • Background
  • 13
  • GDB Version
  • 14
  • Debugging MCJIT-ed code
  • 15
    16
  • Example
  • 17
    1418
    15
    Written by Reid Kleckner
    16
    17
    18

    Example usage

    19
    20
    21
    22

    In order to debug code JITed by LLVM, you need GDB 7.0 or newer, which is

    23 available on most modern distributions of Linux. The version of GDB that Apple
    24 ships with XCode has been frozen at 6.3 for a while. LLDB may be a better
    25 option for debugging JITed code on Mac OS X.
    26

    27
    28

    Consider debugging the following code compiled with clang and run through

    29 lli:
    30

    31
    32
    
                      
                    
    33 #include <stdio.h>
    34
    35 void foo() {
    36 printf("%d\n", *(int*)NULL); // Crash here
    37 }
    38
    39 void bar() {
    40 foo();
    41 }
    42
    43 void baz() {
    44 bar();
    45 }
    46
    47 int main(int argc, char **argv) {
    48 baz();
    49 }
    50
    51
    52

    Here are the commands to run that application under GDB and print the stack

    53 trace at the crash:
    54

    55
    56
    
                      
                    
    57 # Compile foo.c to bitcode. You can use either clang or llvm-gcc with this
    58 # command line. Both require -fexceptions, or the calls are all marked
    59 # 'nounwind' which disables DWARF exception handling info. Custom frontends
    60 # should avoid adding this attribute to JITed code, since it interferes with
    61 # DWARF CFA generation at the moment.
    62 $ clang foo.c -fexceptions -emit-llvm -c -o foo.bc
    63
    64 # Run foo.bc under lli with -jit-emit-debug. If you built lli in debug mode,
    65 # -jit-emit-debug defaults to true.
    66 $ $GDB_INSTALL/gdb --args lli -jit-emit-debug foo.bc
    67 ...
    68
    69 # Run the code.
    70 (gdb) run
    71 Starting program: /tmp/gdb/lli -jit-emit-debug foo.bc
    72 [Thread debugging using libthread_db enabled]
    73
    74 Program received signal SIGSEGV, Segmentation fault.
    75 0x00007ffff7f55164 in foo ()
    76
    77 # Print the backtrace, this time with symbols instead of ??.
    78 (gdb) bt
    79 #0 0x00007ffff7f55164 in foo ()
    80 #1 0x00007ffff7f550f9 in bar ()
    81 #2 0x00007ffff7f55099 in baz ()
    82 #3 0x00007ffff7f5502a in main ()
    83 #4 0x00000000007c0225 in llvm::JIT::runFunction(llvm::Function*,
    84 std::vector<llvm::GenericValue,
    85 std::allocator<llvm::GenericValue> > const&) ()
    86 #5 0x00000000007d6d98 in
    87 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
    88 std::vector<std::string,
    89 std::allocator<std::string> > const&, char const* const*) ()
    90 #6 0x00000000004dab76 in main ()
    91
    92
    93

    As you can see, GDB can correctly unwind the stack and has the appropriate

    94 function names.
    95

    96 </div>
    19 <div class="doc_author">Written by Reid Kleckner and Eli Bendersky</div>
    9720
    9821
    9922

    Background

    10629 no such file to look for.
    10730

    10831
    109

    Depending on the architecture, this can impact the debugging experience in

    110 different ways. For example, on most 32-bit x86 architectures, you can simply
    111 compile with -fno-omit-frame-pointer for GCC and -disable-fp-elim for LLVM.
    112 When GDB creates a backtrace, it can properly unwind the stack, but the stack
    113 frames owned by JITed code have ??'s instead of the appropriate symbol name.
    114 However, on Linux x86_64 in particular, GDB relies on the DWARF call frame
    115 address (CFA) debug information to unwind the stack, so even if you compile
    116 your program to leave the frame pointer untouched, GDB will usually be unable
    117 to unwind the stack past any JITed code stack frames.
    32

    In order to communicate the necessary debug info to GDB, an interface for

    33 registering JITed code with debuggers has been designed and implemented for
    34 GDB and LLVM MCJIT. At a high level, whenever MCJIT generates new machine code,
    35 it does so in an in-memory object file that contains the debug information in
    36 DWARF format. MCJIT then adds this in-memory object file to a global list of
    37 dynamically generated object files and calls a special function
    38 (__jit_debug_register_code) marked noinline that GDB knows about. When
    39 GDB attaches to a process, it puts a breakpoint in this function and loads all
    40 of the object files in the global list. When MCJIT calls the registration
    41 function, GDB catches the breakpoint signal, loads the new object file from
    42 the inferior's memory, and resumes the execution. In this way, GDB can get the
    43 necessary debug information.
    44

    45
    46
    47
    48

    GDB Version

    49
    50
    51

    In order to debug code JIT-ed by LLVM, you need GDB 7.0 or newer, which is

    52 available on most modern distributions of Linux. The version of GDB that Apple
    53 ships with XCode has been frozen at 6.3 for a while. LLDB may be a better
    54 option for debugging JIT-ed code on Mac OS X.
    11855

    11956
    120

    In order to communicate the necessary debug info to GDB, an interface for

    121 registering JITed code with debuggers has been designed and implemented for
    122 GDB and LLVM. At a high level, whenever LLVM generates new machine code, it
    123 also generates an object file in memory containing the debug information. LLVM
    124 then adds the object file to the global list of object files and calls a special
    125 function (__jit_debug_register_code) marked noinline that GDB knows about. When
    126 GDB attaches to a process, it puts a breakpoint in this function and loads all
    127 of the object files in the global list. When LLVM calls the registration
    128 function, GDB catches the breakpoint signal, loads the new object file from
    129 LLVM's memory, and resumes the execution. In this way, GDB can get the
    130 necessary debug information.
    57
    58
    59

    Debugging MCJIT-ed code

    60
    61
    62
    63

    The emerging MCJIT component of LLVM allows full debugging of JIT-ed code with

    64 GDB. This is due to MCJIT's ability to use the MC emitter to provide full
    65 DWARF debugging information to GDB.

    66
    67

    Note that lli has to be passed the -use-mcjit flag to JIT the code

    68 with MCJIT instead of the old JIT.

    69
    70

    Example

    71
    72
    73
    74

    Consider the following C code (with line numbers added to make the example

    75 easier to follow):

    76
    77
    
                      
                    
    78 1 int compute_factorial(int n)
    79 2 {
    80 3 if (n <= 1)
    81 4 return 1;
    82 5
    83 6 int f = n;
    84 7 while (--n > 1)
    85 8 f *= n;
    86 9 return f;
    87 10 }
    88 11
    89 12
    90 13 int main(int argc, char** argv)
    91 14 {
    92 15 if (argc < 2)
    93 16 return -1;
    94 17 char firstletter = argv[1][0];
    95 18 int result = compute_factorial(firstletter - '0');
    96 19
    97 20 // Returned result is clipped at 255...
    98 21 return result;
    99 22 }
    100
    101
    102

    Here is a sample command line session that shows how to build and run this

    103 code via lli inside GDB:
    131104

    132105
    133

    At the time of this writing, LLVM only supports architectures that use ELF

    134 object files and it only generates symbols and DWARF CFA information. However,
    135 it would be easy to add more information to the object file, so we don't need to
    136 coordinate with GDB to get better debug information.
    137 </p>
    106 <pre class="doc_code">
    107 $ $BINPATH/clang -cc1 -O0 -g -emit-llvm showdebug.c
    108 $ gdb --quiet --args $BINPATH/lli -use-mcjit showdebug.ll 5
    109 Reading symbols from $BINPATH/lli...done.
    110 (gdb) b showdebug.c:6
    111 No source file named showdebug.c.
    112 Make breakpoint pending on future shared library load? (y or [n]) y
    113 Breakpoint 1 (showdebug.c:6) pending.
    114 (gdb) r
    115 Starting program: $BINPATH/lli -use-mcjit showdebug.ll 5
    116 [Thread debugging using libthread_db enabled]
    117
    118 Breakpoint 1, compute_factorial (n=5) at showdebug.c:6
    119 6 int f = n;
    120 (gdb) p n
    121 $1 = 5
    122 (gdb) p f
    123 $2 = 0
    124 (gdb) n
    125 7 while (--n > 1)
    126 (gdb) p f
    127 $3 = 5
    128 (gdb) b showdebug.c:9
    129 Breakpoint 2 at 0x7ffff7ed404c: file showdebug.c, line 9.
    130 (gdb) c
    131 Continuing.
    132
    133 Breakpoint 2, compute_factorial (n=1) at showdebug.c:9
    134 9 return f;
    135 (gdb) p f
    136 $4 = 120
    137 (gdb) bt
    138 #0 compute_factorial (n=1) at showdebug.c:9
    139 #1 0x00007ffff7ed40a9 in main (argc=2, argv=0x16677e0) at showdebug.c:18
    140 #2 0x3500000001652748 in ?? ()
    141 #3 0x00000000016677e0 in ?? ()
    142 #4 0x0000000000000002 in ?? ()
    143 #5 0x0000000000d953b3 in llvm::MCJIT::runFunction (this=0x16151f0, F=0x1603020, ArgValues=...) at /home/ebenders_test/llvm_svn_rw/lib/ExecutionEngine/MCJIT/MCJIT.cpp:161
    144 #6 0x0000000000dc8872 in llvm::ExecutionEngine::runFunctionAsMain (this=0x16151f0, Fn=0x1603020, argv=..., envp=0x7fffffffe040)
    145 at /home/ebenders_test/llvm_svn_rw/lib/ExecutionEngine/ExecutionEngine.cpp:397
    146 #7 0x000000000059c583 in main (argc=4, argv=0x7fffffffe018, envp=0x7fffffffe040) at /home/ebenders_test/llvm_svn_rw/tools/lli/lli.cpp:324
    147 (gdb) finish
    148 Run till exit from #0 compute_factorial (n=1) at showdebug.c:9
    149 0x00007ffff7ed40a9 in main (argc=2, argv=0x16677e0) at showdebug.c:18
    150 18 int result = compute_factorial(firstletter - '0');
    151 Value returned is $5 = 120
    152 (gdb) p result
    153 $6 = 23406408
    154 (gdb) n
    155 21 return result;
    156 (gdb) p result
    157 $7 = 120
    158 (gdb) c
    159 Continuing.
    160
    161 Program exited with code 0170.
    162 (gdb)
    163
    164
    165
    138166
    167
    168
    139169
    140170
    141171
    144174 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
    145175
    146176 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
    147 Reid Kleckner
    177 Reid Kleckner,
    178 Eli Bendersky
    148179 The LLVM Compiler Infrastructure
    149180 Last modified: $Date$
    150181