Re: [DynInst_API:] DynInst Overhead

[Buddhika Chamith Kahawitage Don <budkahaw@xxxxxxxxxxxx>]

I did a little bit of debugging with gdb. This stray entry seems to be the first element of the vector returned from the call toÂappImage->getModules () where appImage is theÂBPatch_image.

On Mon, Jul 28, 2014 at 7:01 PM, Buddhika Chamith Kahawitage Don <budkahaw@xxxxxxxxxxxx> wrote:

Yes. That output is coming from CodeCoverage.C apparently when it is trying iterate the module list.

    if ((*moduleIter)->isSharedLib ()) {

      if (!includeSharedLib

          || skipLibraries.find (moduleName) != skipLibraries.end ()) {

        cout << "Skipping library: " << moduleName << endl;

        continue;

      }

    }

I have attached the output. The interesting bit of output seems to be the following.

Instrumenting Basic Block 0x40b695 of BZ2_hbMakeCodeLengths

Instrumenting Basic Block 0x40b69c of BZ2_hbMakeCodeLengths

Instrumenting Basic Block 0x40b6a5 of BZ2_hbMakeCodeLengths

Instrumenting Basic Block 0x40b6b4 of BZ2_hbMakeCodeLengths

Instrumenting Basic Block 0x40b6c6 of BZ2_hbMakeCodeLengths

Inserting instrumention at function entry of __libc_csu_fini

Instrumenting Basic Block 0x40b6d0 of __libc_csu_fini

Skipping library: ld-linux-x86-64.so.2

Skipping library: libc.so.6

insertInitCallback on huffman.c

insertFiniCallback on huffman.c

ÂcreateSymbolTables for ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂQ

::driver for emitElf64

Emitting to temporary file bzipsfJyqC

section .interp addr = 400200 off = 238 size = 1c

section .note.ABI-tag addr = 40021c off = 121c size = 20

section .note.gnu.build-id addr = 40023c off = 123c size = 24

section .gnu.hash addr = 400260 off = 1260 size = 24

I also checked my LD_LIBRARY_PATH and LD_LIBRARY entries for any weird stuff just in case and found none.

Regards

Bud

On Mon, Jul 28, 2014 at 5:10 PM, Bill Williams <bill@xxxxxxxxxxx> wrote:

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