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 <
budka...@umail.iu.edu> 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 <b...@cs.wisc.edu> 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 <b...@cs.wisc.edu
>>> <mailto:b...@cs.wisc.edu>> 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 <b...@cs.wisc.edu
>>> <mailto:b...@cs.wisc.edu>
>>> <mailto:b...@cs.wisc.edu <mailto:b...@cs.wisc.edu>>> 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
>>> <budka...@umail.iu.edu <mailto:budka...@umail.iu.edu>
>>> <mailto:budka...@umail.iu.edu <mailto:budka...@umail.iu.edu>>
>>> <mailto:budka...@umail.iu.edu
>>> <mailto:budka...@umail.iu.edu> <mailto:budka...@umail.iu.edu
>>> <mailto:budka...@umail.iu.edu>>__>__>
>>>
>>> wrote:
>>>
>>> Will try that out.
>>>
>>> Thanks
>>> Bud
>>>
>>>
>>> On Tue, Jul 22, 2014 at 2:06 PM, Matthew LeGendre
>>> <legend...@llnl.gov <mailto:legend...@llnl.gov>
>>> <mailto:legend...@llnl.gov <mailto:legend...@llnl.gov>>
>>> <mailto:legend...@llnl.gov <mailto:legend...@llnl.gov>
>>> <mailto:legend...@llnl.gov <mailto:legend...@llnl.gov>>>> 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
>>> b...@cs.wisc.edu <mailto:b...@cs.wisc.edu>
>>> <mailto:b...@cs.wisc.edu <mailto:b...@cs.wisc.edu>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --bw
>>>
>>> Bill Williams
>>> Paradyn Project
>>> b...@cs.wisc.edu <mailto:b...@cs.wisc.edu>
>>>
>>>
>>>
>>
>> --
>> --bw
>>
>> Bill Williams
>> Paradyn Project
>> b...@cs.wisc.edu
>>
>
>
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
