Re: Specifying a debuginfo path independently of sysroot

[Rick Moseley <rmoseley@redhat.com>]

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
>>
>