Re: [DynInst_API:] Dyninst limitations for memory trace


Date: Tue, 23 Oct 2012 14:19:39 +0200
From: Pooya Salehi <pxsalehi@xxxxxxxxx>
Subject: Re: [DynInst_API:] Dyninst limitations for memory trace
Thank you for your responses. I will try to get a clean installation
of Dyninst since apparently all of the problems seems to be caused by
incorrect installation/configuration!

On 10/22/12, Josh Stone <jistone@xxxxxxxxxx> wrote:
> On 10/21/2012 10:24 PM, Legendre, Matthew P. wrote:
>> I believe the "Unable to find function: dyn_pthread_self" error is
>> frequently from a misset DYNINSTAPI_RT_LIB environment variable.  Make
>> sure that's pointed to the full path to libdyninstAPI_RT.so.  A common
>> mistake would be pointing it to libdyninstAPI.so.
>
> On that note, I found it pretty cumbersome that this environment
> variable needs to be set all the time, so I figured out a trick that you
> may like to get it dynamically.  See guess_dyninst_rt() here:
>
> http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=blob;f=stapdyn/dynutil.cxx;h=393a14231e35baf075149cef03076b799551c6e0;hb=HEAD#l30
>
> That won't work for cross-arch mutatees (i.e. needing RT_m32), but
> otherwise it does the job well, since native is most common for us.
> Even if we could figure out m32, you're still stuck if you want a mix of
> 64 & 32-bit mutatees at once, since there's only one environment
> variable to set!  (Hmm, can dyninst handle a "/path1:/path2" env?)
>
>
> Josh
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>
[← Prev in Thread] Current Thread [Next in Thread→]