From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8682 invoked by alias); 8 May 2008 18:44:37 -0000 Received: (qmail 8672 invoked by uid 22791); 8 May 2008 18:44:36 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 May 2008 18:44:18 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id D4F773C1D4; Thu, 8 May 2008 11:44:16 -0700 (PDT) Subject: Re: Debugging new code using debug-info from old code From: Michael Snyder To: Lokesh Kumar Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 08 May 2008 18:44:00 -0000 Message-Id: <1210272256.4615.487.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-05/txt/msg00068.txt.bz2 On Wed, 2008-05-07 at 17:29 -0700, Lokesh Kumar wrote: > Hi all, > > I am trying to debug a "transformed" C code using the debugging > information of the "original" C code. Essentially, my code goes > through some transformations that keeps its semantic structure same > but add some extraneous function calls distributed throughout the > code. > > I want that when a user debugs this new code, all the new additions > are hidden away from him/her and (s)he feels as if (s)he is debugging > the original code. What this means is that there should exists an > underlying mapping between the transformed code and original code so > that it could map the debugging commands for original code into > corresponding commands for transformed code. > > I started out by trying to load the symbol table of the original > executable while debugging the transformed binary but that doesn't > seem to help since the function addresses and everything else has > changed. My second thoughts seem to suggest that if I can update the > debugging information in the transformed binary as per my original > code, I may get what I want. However, I am not sure how this will work > if there were some compile-time optimizations in one code and not in > another but I am not thinking about that now. > > I think I can use some help here. Does anyone here have a better idea > on how to do it ? Or perhaps, how can I update the debugging > information from one binary to another ? This has been done before -- for instance, this is how the original "cfront" c++ compiler worked. "cfront" would pre-process the C++ source code and generate a transformed C program file, which would then be compiled. In order to make debuggers (notably gdb) display the un-preprocessed C++ source instead of the processed C source, cfront would generate "#line" directives in the output (C) program that referred back to lines within the input (C++) program. So, if your transformed output file contains some code that is associated with, say, line 1000 of your input source file, you would instrument the output file with a line directive that would look something like #line 1000 'input.c' Try it. You can add some line directives by hand and compile the code to experiment with the debugger behavior.