From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10230 invoked by alias); 31 Mar 2009 19:34:03 -0000 Received: (qmail 9821 invoked by uid 22791); 31 Mar 2009 19:34:00 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Mar 2009 19:33:54 +0000 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n2VJXokU026896 for ; Tue, 31 Mar 2009 20:33:50 +0100 Received: from an-out-0708.google.com (andd11.prod.google.com [10.100.30.11]) by zps75.corp.google.com with ESMTP id n2VJXmvD007362 for ; Tue, 31 Mar 2009 12:33:48 -0700 Received: by an-out-0708.google.com with SMTP id d11so1753134and.13 for ; Tue, 31 Mar 2009 12:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.6.16 with SMTP id 16mr5372533anf.23.1238528027859; Tue, 31 Mar 2009 12:33:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Mar 2009 19:34:00 -0000 Message-ID: Subject: Re: [LLVMdev] Connecting JITted code to gdb From: Jeffrey Yasskin To: LLVM Developers Mailing List , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00197.txt.bz2 I'm adding the gdb list because it appears there's currently no way to tell gdb about newly-JITted code. That is, it's not an LLVM-specific problem. There appear to be two techniques in common use to debug dynamically-generated code despite this. First, as Evan suggests below, we can have the JIT print the address range that it's written a function into, have gdb disassemble that, set breakpoints at particular addresses, and print variables by knowing what register they live in. Second, as described at http://www.mono-project.com/Debugging#Debugging_with_GDB_in_XDEBUG_mode, we can write out a full object file with dwarf tables, and use add-symbol-file to get gdb to load that on demand. Neither of these is ideal. add-symbol-file is better, but it doesn't allow us to set breakpoints inside the JITted code until it's generated, and it doesn't let those breakpoints follow the code as it's re-optimized and re-translated. It currently also requires user interaction, but it's possible that we could write a -gdb.py file to reload the debug information every time the user gets to the gdb prompt. There may be other problems I haven't though of. It would be better to have an interface through which a JITting library could tell gdb about newly-generated code. This could resemble the overlay interface (http://sourceware.org/gdb/current/onlinedocs/gdb_13.html#SEC108) or the interface through which dynamic loaders tell gdb about newly-loaded code. There are a couple considerations that are specific to JITting, of course: 1. A JIT compiler generates new code frequently, and having to do lots of extra work, especially while the debugger isn't attached, may hurt performance. 2. Translated code gets duplicated, replaced, and freed, and gdb needs to modify its breakpoints to keep up. I don't really know enough about the internals of LLVM or gdb to make any recommendations, but I think it would be useful to find some way for them (and other debuggers and JITs) to talk to each other. Jeffrey On Fri, Mar 27, 2009 at 1:48 PM, Evan Cheng wrote: > Run with -debug-only=jit. > > Break on line 1148 of JITEmitter.cpp. The debugging message will tell > you the address and size of the function that was jitted. You can then > tell gdb to disassemble the code.