From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25001 invoked by alias); 13 Jun 2008 15:56:46 -0000 Received: (qmail 24988 invoked by uid 22791); 13 Jun 2008 15:56:45 -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; Fri, 13 Jun 2008 15:56:27 +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 m5DFuPfo021451 for ; Fri, 13 Jun 2008 11:56:25 -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 m5DFuOrg027014 for ; Fri, 13 Jun 2008 11:56:24 -0400 Received: from localhost.localdomain (vpn-15-37.rdu.redhat.com [10.11.15.37]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5DFuM2T020225 for ; Fri, 13 Jun 2008 11:56:23 -0400 Message-ID: <485298A6.3070203@redhat.com> Date: Fri, 13 Jun 2008 21:14:00 -0000 From: Rick Moseley User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: frysk@sourceware.org Subject: Re: Specifying a debuginfo path independently of sysroot References: <962B19CF-9923-42EC-9732-BFE1AB7E07DB@sybase.com> <4852804D.30601@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/msg00104.txt.bz2 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 >> >