From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2386 invoked by alias); 16 Jun 2008 13:20:28 -0000 Received: (qmail 2379 invoked by uid 22791); 16 Jun 2008 13:20:27 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jun 2008 13:20:05 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5GDK3Un004238; Mon, 16 Jun 2008 09:20:03 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5GDK19p031036; Mon, 16 Jun 2008 09:20:02 -0400 Received: from localhost.localdomain (vpn-14-84.rdu.redhat.com [10.11.14.84]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5GDK0G3000744; Mon, 16 Jun 2008 09:20:00 -0400 Message-ID: <48566880.1040003@redhat.com> Date: Wed, 18 Jun 2008 13:27:00 -0000 From: Rick Moseley User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ray Ruvinskiy CC: frysk@sourceware.org Subject: Re: Specifying a debuginfo path independently of sysroot References: <962B19CF-9923-42EC-9732-BFE1AB7E07DB@sybase.com> <4852804D.30601@redhat.com> <485298A6.3070203@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00108.txt.bz2 Ray Ruvinskiy wrote: > Hi Rick, > > The environment variable idea sounds good to me personally. Would this > be checked in DwflCache.getDwfl before calling getRelativeSysroot and > instantiating the new Dwfl instance? That sounds right to me, although I am not familiar with that code. > > Still, I don't fully understand why getRelativeSysroot always prepends > the hardcoded "/usr/lib/debug" to anything you pass in. While that is > the standard location to put debug files for binaries that go in /usr, > what about software that goes in /usr/local or /opt? > > Thanks, > > Ray > > On 13-Jun-08, at 11:56 AM, Rick Moseley wrote: > >> Hi Ray, >> >> I was trying to think of a good/simple/easy way to do this. I wonder >> if we could set some sort of shell variable similar to >> "LD_LIBRARY_PATH", maybe "FRYSK_DEBUGINFO_PATH" that we could >> interrogate and if there is a path there use it first to search for >> the debuginfo and failing that then look in the usual places. >> >> Another probably idea is to have a file either in ~/.frysk or just in >> ~ called something like .fryskdebuginfopath that has a line with the >> initial paths to search. If that file exists, search those first and >> the usual places last. Would make it better than having to override >> with a commandline command every time. >> >> Just a couple of thoughts. >> >> Rick >> >> >> Ray Ruvinskiy wrote: >>> Hi Sami, >>> >>> We save debug symbols for every build on a central server. The >>> binaries that are tested (and shipped) are stripped, except for a >>> gnu_debuglink. To debug issues on QA machines or customer issues, we >>> find it convenient to simply create a symbolic .debug link from the >>> directory where the binaries and libraries are installed to where we >>> keep the symbols for the particular build we want to debug. The >>> directory structure of the symbol repository does not necessarily >>> match the directory structure of the location where the software was >>> installed. >>> >>> Thanks, >>> >>> Ray >>> >>> On 13-Jun-08, at 10:12 AM, Sami Wagiaalla wrote: >>> >>>> Hi Ray, >>>> >>>>> I was wondering if it was possible to pass a custom debuginfo path >>>>> from frysk to libdwfl without using the -sysroot switch. >>>> >>>> I guess the first question is why would one want to do this >>>> ?..maybe there is a larger problem that we should fix, also for the >>>> record :) >>>> >>>>> If this is not currently possible, I was wondering if it might be >>>>> desirable to allow for this. I wouldn't mind taking a crack at >>>>> implementing this, if given an idea as to what semantics would be >>>>> desired. >>>> >>>> If you do go for it here are a couple of things to look out for: >>>> >>>> 1) I think CommandLineParser.java would be a good spot to add it so >>>> that the functionality tricles down to all the command line utilities. >>>> >>>> 2) We are currently in a slow switch from CNI to JNI so we have two >>>> sets of bindings that we are maintaining. So if you do touch the >>>> bindings make sure you update the JNI side of things... hopefully >>>> this would be over by frysk 0.5 :) >>>> >>>> 3) It would be really cool if your patch comes with a test case. >>>> The frysk test suite is nice to work with now-a-days. You can find >>>> examples in Test*.java... then copy/paste and edit. >>>> >>>> Cheers, >>>> Sami >>>> >>> >> >> >