From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16281 invoked by alias); 22 Jul 2009 23:17:57 -0000 Received: (qmail 16265 invoked by uid 22791); 22 Jul 2009 23:17:56 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f205.google.com (HELO mail-bw0-f205.google.com) (209.85.218.205) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Jul 2009 23:17:50 +0000 Received: by bwz1 with SMTP id 1so501297bwz.24 for ; Wed, 22 Jul 2009 16:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.132.147 with SMTP id 19mr137618hbr.153.1248304667075; Wed, 22 Jul 2009 16:17:47 -0700 (PDT) In-Reply-To: <9a9942200907221615o570e749fh5cb186c1600f159c@mail.gmail.com> References: <9a9942200907221615o570e749fh5cb186c1600f159c@mail.gmail.com> From: Reid Kleckner Date: Thu, 23 Jul 2009 12:08:00 -0000 Message-ID: <9a9942200907221617r4d9d2264q52b4c6605d4389c7@mail.gmail.com> Subject: Re: [RFA] Add interface for registering JITed code To: gdb-patches@sourceware.org, unladen-swallow@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00574.txt.bz2 + unladen-swallow On Wed, Jul 22, 2009 at 4:15 PM, Reid Kleckner wrote: > Hi, > > I'm working on unladen swallow, and we're trying to speed up Python by > using the LLVM JIT. =A0However, when we merge back to mainline, we want > developers to be able to debug CPython with GDB. =A0So that means we > need LLVM to generate dwarf debug info, and we need to register it > with GDB. =A0After talking with some GDB developers here at Google, we > decided the best way to do this was to mirror the dlopen/dlclose > interface. > > On the LLVM side, for each JITed function we create a small ELF in > memory with the debug info and symbol. =A0LLVM then writes a little code > entry struct describing the ELF, adds it to a linked list, and calls > __jit_debug_register_code. > > I've added a breakpoint at __jit_debug_register_code and a > corresponding event handler on the GDB side, which then reads the code > entry out of another special global symbol (__jit_debug_descriptor). > GDB then copies over the ELF and creates a BFD with it in memory, as > is done in symbol-file-from-memory. =A0Then it can call > add_symbol_file_from_bfd with the BFD, and life is good. > > If GDB attaches while the program is running, it reads the linked list > of code entries from the descriptor and registers each ELF as above. > > If LLVM frees machine code, then it sets the action enum in the > descriptor to JIT_UNREGISTER, points the descriptor at the relevant > code entry, and calls __jit_debug_register_code again. =A0This way, GDB > can turn around and free the corresponding object file. =A0It's a nicer > interface than the shared library interface because it actually passes > the relevant entry, so you don't have to iterate over the linked list > in the inferior. > > Finally, if the inferior exits, GDB goes through and tosses out all > the JITed object files. > > One nice thing about this interface is that we don't have to reinvent > another "file" format to encode the debug information, but it is > annoying that it requires the JIT to link in an object file writer. > Right now LLVM only has call frame information support (which they use > for dwarf exception handling), but they have plans to add more after > this summer. =A0With this interface, we don't have to change anything on > the GDB side when that happens. > > Here is a demo of what this does on x86_64, which relies on call frame > information to produce a backtrace. > > Without the interface, the backtrace is totally garbled (it has way > too many frames) in addition to not having symbols: > > [rnk@knuckles llvm-gdb-64]$ gdb Debug/bin/lli > GNU gdb 6.8-gg16 > ... > (gdb) run t.bc > ... > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff7fd86f0 (LWP 15017)] > (gdb) bt > #0 =A00x00007ffff61441a4 in ?? () > #1 =A00x0000000000000003 in ?? () > #2 =A00x0000000000000004 in ?? () > #3 =A00x00037ffff5f43fd0 in ?? () > #4 =A00x00007ffff614411c in ?? () > #5 =A00x00027fff00000003 in ?? () > #6 =A00x00007ffff61440aa in ?? () > #7 =A00x01000002f5f43ff0 in ?? () > #8 =A00x00007ffff614402c in ?? () > #9 =A00x0100000000000001 in ?? () > #10 0x0000000001438a40 in ?? () > #11 0x00007fff00000001 in ?? () > #12 0x0000000000b84d63 in llvm::JIT::runFunction (this=3D0x1405900, F=3D0= x1402e10, > =A0 =A0ArgValues=3D@0x7fffffffdfd0) > =A0 =A0at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:411 > #13 0x0000000000ba8985 in llvm::ExecutionEngine::runFunctionAsMain ( > =A0 =A0this=3D0x1405900, Fn=3D0x1402e10, argv=3D@0x13efab8, envp=3D0x7fff= ffffe3a0) > =A0 =A0at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:378 > #14 0x00000000007e8635 in main (argc=3D2, argv=3D0x7fffffffe388, > =A0 =A0envp=3D0x7fffffffe3a0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:220 > (gdb) > > With the interface, it has symbols and no extra frames: > > [rnk@knuckles llvm-gdb-64]$ ../gdb-jit-64/gdb/gdb Debug/bin/lli > ... > (gdb) run t.bc > ... > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff61441a4 in baz () > (gdb) bt > #0 =A00x00007ffff61441a4 in baz () > #1 =A00x00007ffff614411c in bar () > #2 =A00x00007ffff61440aa in foo () > #3 =A00x00007ffff614402c in main () > #4 =A00x0000000000b84d63 in llvm::JIT::runFunction (this=3D0x1405900, F= =3D0x1402e10, > =A0 =A0ArgValues=3D...) at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT= .cpp:411 > #5 =A00x0000000000ba8985 in llvm::ExecutionEngine::runFunctionAsMain ( > =A0 =A0this=3D0x1405900, Fn=3D0x1402e10, argv=3D..., envp=3D0x7fffffffe39= 0) > =A0 =A0at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:378 > #6 =A00x00000000007e8635 in main (argc=3D2, argv=3D0x7fffffffe378, > =A0 =A0envp=3D0x7fffffffe390) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:220 > (gdb) > > I've tested this on x86_64 debugging both 64-bit and 32-bit inferiors. > > Please review! > > Thanks, > Reid >