From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12068 invoked by alias); 13 Jun 2008 21:14:54 -0000 Received: (qmail 12056 invoked by uid 22791); 13 Jun 2008 21:14:52 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from fm200.sybase.com (HELO fm200.sybase.com) (192.138.151.122) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jun 2008 21:14:35 +0000 Received: from smtp2.sybase.com (sybgate2.sybase.com [10.22.97.85]) by fm200.sybase.com with ESMTP id m5DLEGY09547; Fri, 13 Jun 2008 14:14:17 -0700 (PDT) Received: from gwwest.sybase.com (localhost [127.0.0.1]) by smtp2.sybase.com with ESMTP id m5DLEGe03460; Fri, 13 Jun 2008 14:14:16 -0700 (PDT) Received: from rruvinsk-osx.sybase.com ([10.25.107.13]) by waterloomail1.sybase.com (Lotus Domino Release 6.5.4) with ESMTP id 2008061317141451-7170 ; Fri, 13 Jun 2008 17:14:14 -0400 Cc: frysk@sourceware.org Message-Id: From: Ray Ruvinskiy To: Rick Moseley In-Reply-To: <485298A6.3070203@redhat.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Specifying a debuginfo path independently of sysroot Date: Mon, 16 Jun 2008 12:22:00 -0000 References: <962B19CF-9923-42EC-9732-BFE1AB7E07DB@sybase.com> <4852804D.30601@redhat.com> <485298A6.3070203@redhat.com> X-Mailer: Apple Mail (2.919.2) X-MIMETrack: Itemize by SMTP Server on WaterlooMail1/SYBASE(Release 6.5.4|March 27, 2005) at 06/13/2008 05:14:14 PM, Serialize by Router on gwwest/SYBASE(Release 6.5.5|November 30, 2005) at 06/13/2008 02:14:16 PM, Serialize complete at 06/13/2008 02:14:16 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes 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/msg00105.txt.bz2 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? 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 >>> >> > >