Re: [DynInst_API:] DynInst Overhead

[Bill Williams <bill@xxxxxxxxxxx>]

On 07/25/2014 10:53 PM, Buddhika Chamith Kahawitage Don wrote:
> Yes that did the trick. Thanks. But that doesn't seem to be the end of
> the road unfortunately :(. I tried instrumenting several apps. I see
> following inconsistent behavior.
>
> Initially the instrumentation starts with following message for all apps.
...I've been through our source and can't find the source of this log 
message anywhere inside the Dyninst tree. Is this coming from the 
mutator by chance? And if so, can you poke in a debugger and find where 
the ostensible library name is coming from and what it looks like as a 
hex dump?
I mean, it seems obvious that this is an attempt to open/instrument a 
library dependency with a bogus (corrupt? missing? whole library entry 
is invalid?) pathname, skipping it, copying it over into the rewritten 
binary's DT_NEEDED entries, and the loader horking that <arbitrary line 
noise> is not a loadable library. What's not obvious is where this bogus 
dependency came from--I haven't seen this in any of our testing.
Can you turn on SYMTAB_DEBUG_REWRITE in your environment and send me 
that log?
> "Skipping library: ïïïïïïïïïïïïïïïï1"
>
> Then some of the apps fails when executed with the following message.
>
> "error while loading shared libraries: ïïïïïïïïïïïïïïïïQ: cannot open
> shared object file: No such file or directory"
>
> So I checked the ldd output from before and after instrumentation for a
> such application.
>
> Before
>
> $ ldd bzip2
>      linux-vdso.so.1 =>  (0x00007fff23fff000)
>      libc.so.6 => /lib64/libc.so.6 (0x0000003acc200000)
>      /lib64/ld-linux-x86-64.so.2 (0x0000003acbe00000)
>
> After
>
> $ ldd bz
>      linux-vdso.so.1 =>  (0x00007fffba172000)
>      libc.so.6 => /lib64/libc.so.6 (0x0000003acc200000)
>      ./libInst.so (0x00007f8673335000)
>      /home/buddhikac/dyninst/build/lib/libdyninstAPI_RT.so.8.2
> (0x00007f867209b000)
>       => /lib64/ld-linux-x86-64.so.2 (0x0000003acbe00000)
>      ïïïïïïïïïïïïïïïïQ => not found
>      libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ad0200000)
>      libm.so.6 => /lib64/libm.so.6 (0x0000003acca00000)
>      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003acf600000)
>      libdl.so.2 => /lib64/libdl.so.2 (0x0000003acc600000)
>
> Where it seems to be that a stray entry has been added during
> instrumentation. Not sure what to make of this. Any ideas?
>
> Bud
>
>
>
>
> On Fri, Jul 25, 2014 at 11:11 AM, Bill Williams <bill@xxxxxxxxxxx
> <mailto:bill@xxxxxxxxxxx>> wrote:
>
>     On 07/25/2014 01:53 AM, Buddhika Chamith Kahawitage Don wrote:
>
>         Thanks for the input. I finally manage to get the build working.
>         However
>         when I try to run the code-coverage tool linked to this version
>         I get
>         the following.
>
>         codeCoverage: ~/dyninst/dyninstAPI/src/__binaryEdit.C:928:
>         int_variable*
>         BinaryEdit::createTrampGuard()__: Assertion `var' failed.
>         Aborted
>
>         Is this something which sounds familiar?
>
>     Yes; is your DYNINSTAPI_RT_LIB environment variable set to point to
>     libdyninstAPI_RT.so's full pathname? And does libdyninstAPI_RT.so
>     have a public DYNINST_default_tramp_guards symbol?
>
>         Regards
>         Bud
>
>
>
>         On Thu, Jul 24, 2014 at 1:38 PM, Bill Williams <bill@xxxxxxxxxxx
>         <mailto:bill@xxxxxxxxxxx>
>         <mailto:bill@xxxxxxxxxxx <mailto:bill@xxxxxxxxxxx>>> wrote:
>
>              On 07/24/2014 12:35 PM, Buddhika Chamith Kahawitage Don wrote:
>
>                  I tried clearing old install and I am still getting
>         that error.
>                  Apparently eventhough entryIDs.h file contain this
>         entry it's not
>                  getting properly included in arch-X86.C file during
>         compilation.
>
>                  Since I am not familiar with CMake builds (it seems to
>         generate
>                  lot of
>                  intermediate build files) I am not sure where to look
>         to debug this
>                  issue. Any pointers would be greatly appreciated.
>
>              IIRC entryIDs.h moved in our build structure between 8.1.2
>         and 8.2;
>              you could be picking up an old copy from the build tree
>         rather than
>              from the installed location.
>
>              I haven't seen this on actually clean checkouts, so you've
>         still got
>              a second entryIDs.h kicking around somewhere...
>
>                  Regards
>                  Bud
>
>
>
>                  On Tue, Jul 22, 2014 at 8:23 PM, Buddhika Chamith
>         Kahawitage Don
>                  <budkahaw@xxxxxxxxxxxx <mailto:budkahaw@xxxxxxxxxxxx>
>         <mailto:budkahaw@xxxxxxxxxxxx <mailto:budkahaw@xxxxxxxxxxxx>>
>                  <mailto:budkahaw@xxxxxxxxxxxx
>         <mailto:budkahaw@xxxxxxxxxxxx> <mailto:budkahaw@xxxxxxxxxxxx
>         <mailto:budkahaw@xxxxxxxxxxxx>>__>__>
>                  wrote:
>
>                       Will try that out.
>
>                       Thanks
>                       Bud
>
>
>                       On Tue, Jul 22, 2014 at 2:06 PM, Matthew LeGendre
>                       <legendre1@xxxxxxxx <mailto:legendre1@xxxxxxxx>
>         <mailto:legendre1@xxxxxxxx <mailto:legendre1@xxxxxxxx>>
>                  <mailto:legendre1@xxxxxxxx <mailto:legendre1@xxxxxxxx>
>         <mailto:legendre1@xxxxxxxx <mailto:legendre1@xxxxxxxx>>>> wrote:
>
>
>
>                           On Mon, 21 Jul 2014, Buddhika Chamith
>         Kahawitage Don wrote:
>
>                               I tried building v8.2 branch but got the
>         following
>                  error.
>
>                               arch-x86.C:368: error: âe_cmpsd_sseâ was not
>                  declared in
>                               this scope
>
>                               Really appreciate if you can (re)post the
>         build
>                               instructions. I tried
>                               browsing the list archive. But couldn't
>         find any
>                  specific
>                               build how-to. May
>                               be I missed it due to the message volume.
>
>
>                           The cmpsd_sse instructions were only added to
>         v8.2 a
>                  month ago
>                           by Ray. They weren't in Dyninst 8.1.  I'd bet your
>                  install is
>                           pulling the old 8.1 header files (specifically
>                  entryID.h, where
>                           e_cmpsd_sse is defined) and mixing them with
>         the new
>                  8.2 source.
>                             Try clearing out your old install and see if
>         that
>                  fixes the build.
>
>                           -Matt
>
>
>
>
>
>              --
>              --bw
>
>              Bill Williams
>              Paradyn Project
>         bill@xxxxxxxxxxx <mailto:bill@xxxxxxxxxxx>
>         <mailto:bill@xxxxxxxxxxx <mailto:bill@xxxxxxxxxxx>>
>
>
>
>
>     --
>     --bw
>
>     Bill Williams
>     Paradyn Project
>     bill@xxxxxxxxxxx <mailto:bill@xxxxxxxxxxx>

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx