From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27739 invoked by alias); 10 Jun 2005 20:10:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27728 invoked by uid 22791); 10 Jun 2005 20:10:33 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 10 Jun 2005 20:10:33 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5AKAT3x009190; Fri, 10 Jun 2005 16:10:29 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5AKARO07718; Fri, 10 Jun 2005 16:10:27 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j5AKAFZF032438; Fri, 10 Jun 2005 16:10:16 -0400 Message-ID: <42A9F3A4.9080001@redhat.com> Date: Fri, 10 Jun 2005 20:10:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sourceware.org Subject: Re: RFC: Improve support for "debugging" unlinked objects References: <20050608214956.GA10586@nevyn.them.org> In-Reply-To: <20050608214956.GA10586@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg00095.txt.bz2 Daniel Jacobowitz wrote: > If you compile a file containing both code and initialized data, and load > the unlinked object (.o) file using GDB, "print Variable" won't work. > You'll get garbage-looking data, which is in fact the start of the first > section in the file - usually .text. > > All sections appear to have address 0. i.e., they overlap, sort of like > overlays but not similar enough to reuse the overlay machinery. For this > case, if we fill in section_offsets, we can place them at random locations > which are sufficiently unique that we can see the locations of variables as > distinct. And if we pass this information back to exec.c, we can see the > values of variables correctly, too. > > Here's a patch along with a testcase; the test fails before the patch, and > passes afterwards. Any comments on the way I fixed this? > I think this is a great idea, and... > Also, with a fix that I'm going to commit to bfd soon, you > can use "gdb -write" to patch an object file. this bit's especially great. One suggestion -- could you use the section's file offset in place of a "random location"? I'm guessing it's available from bfd, and it seems to me that it's guaranteed to be unique. There might be some advantage in terms of following non-relocated branches etc. Michael