Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Buddhika Chamith Kahawitage Don
I see. I was checking if there is a convenient catch all header which we
can use per each API rather than including multitude of includes according
to usage. Looks like there is not?

Thanks for the catch.


On Thu, Jan 24, 2019 at 10:53 PM Xiaozhu Meng  wrote:

> It looks like you will need to do:
>
> #include "BPatch_object.h"
>
> On Thu, Jan 24, 2019 at 10:23 AM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> By the way function PopulateUsedRegisters in the error I sent earlier
>> accepts a Dyninst::ParseAPI::CodeObject* as the first parameter.
>>
>> On Thu, Jan 24, 2019 at 9:51 PM Buddhika Chamith Kahawitage Don <
>> budka...@iu.edu> wrote:
>>
>>> Aah yes. That was a typo. My bad. However the code I tried have it
>>> correct which still fails :(. I think the failure happens at convert
>>> function call before the assignment.
>>>
>>> On Thu, Jan 24, 2019 at 9:47 PM Xiaozhu Meng  wrote:
>>>
 On Thu, Jan 24, 2019 at 10:05 AM Buddhika Chamith Kahawitage Don <
 budka...@iu.edu> wrote:

> Hi Xiaozhu,
>
> I did the following. I think I am missing something below. Can you
> please check and let me know..
>
>   BPatch* bpatch = new BPatch;
>

>   // open binary and  dependencies
>   BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);
>
>   BPatch_image* image = app->getImage();
>
>   std::vector objects;
>   image->getObjects(objects);
>
>   for (auto object : objects) {
>Dyninst::ParseAPI::CodeObject co =
> Dyninst::ParseAPI::convert(object);
>   }
>
> It looks like you missed a * for the CodeObject pointer declaration:

 Dyninst::ParseAPI::CodeObject *** co = Dyninst::ParseAPI::convert(
 object);


> It fails with
>
> src/register_usage.cc:190:54: error: cannot initialize a parameter of
> type 'const BPatch_function *' with an lvalue of type 'BPatch_object *'
> PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);
>
> So obviously it's the wrong usage of the API. I am having trouble
> piecing together correct sequence of API calls for this. Appreciate your
> help.
>
> Cheers
>
>
>
> On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> Hi Andreas,
>>
>> Thanks for the input. You are exactly right! :). I was looking for an
>> output similar to what ldd provides. My use case is to get register usage
>> patterns in a given binary and its linked shared libraries.
>>
>> On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng 
>> wrote:
>>
>>> Another approach is to use BPatch_binaryEdit to open the binary,
>>> which has an option parameter to specify whether also opening its
>>> dependencies. Then you can convert BPatch_object to 
>>> ParseAPI::CodeObject by
>>> doing:
>>>
>>> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>>>
>>>
>> @ Xiaozhu. I will check this out as well. Thanks!
>>
>>
>>> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
>>> wrote:
>>>
 Hi,

 jumping into the conversation as I'm also doing research on shared
 libraries and (in a broader sense) instrumentation as part of my
 PhD at
 the University Erlangen-Nürnberg. :)

 On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
 > It doesn't seem to provide the full path to the linked library,
 just the
 > library name. So when I use the return value to construct a
 > SymtabCodeSource it fails. Any idea how to get the full path of
 the
 > linked library?
 >

 That depends on your current system and the execution environment.
 If
 you're looking at the executable or shared library using 'readelf'
 (for
 example with the -e parameter), you see that the file itself will
 only
 specify the (file-)name of the library it requires. The actual
 resolution to an absolute path is done in the linker and will take
 default library search paths as well as the LD_LIBRARY_PATH and
 LD_PRELOAD environment variables into account.

 If you're on the system you want to analyze and want to see which
 libraries a given binary loads, try running 'ldd' on the binary in
 question, this will run the linker up to the point right before
 execution is handed over to the binary itself and print all
 imported
 libraries as well as their paths.

 I'm quite interested in what you're working on, if you'd like you
 can
 drop me a private mail.

 Regards,

 Andreas


 > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
 > 

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Xiaozhu Meng
It looks like you will need to do:

#include "BPatch_object.h"

On Thu, Jan 24, 2019 at 10:23 AM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> By the way function PopulateUsedRegisters in the error I sent earlier
> accepts a Dyninst::ParseAPI::CodeObject* as the first parameter.
>
> On Thu, Jan 24, 2019 at 9:51 PM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> Aah yes. That was a typo. My bad. However the code I tried have it
>> correct which still fails :(. I think the failure happens at convert
>> function call before the assignment.
>>
>> On Thu, Jan 24, 2019 at 9:47 PM Xiaozhu Meng  wrote:
>>
>>> On Thu, Jan 24, 2019 at 10:05 AM Buddhika Chamith Kahawitage Don <
>>> budka...@iu.edu> wrote:
>>>
 Hi Xiaozhu,

 I did the following. I think I am missing something below. Can you
 please check and let me know..

   BPatch* bpatch = new BPatch;

>>>
   // open binary and  dependencies
   BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);

   BPatch_image* image = app->getImage();

   std::vector objects;
   image->getObjects(objects);

   for (auto object : objects) {
Dyninst::ParseAPI::CodeObject co =
 Dyninst::ParseAPI::convert(object);
   }

 It looks like you missed a * for the CodeObject pointer declaration:
>>>
>>> Dyninst::ParseAPI::CodeObject *** co = Dyninst::ParseAPI::convert(
>>> object);
>>>
>>>
 It fails with

 src/register_usage.cc:190:54: error: cannot initialize a parameter of
 type 'const BPatch_function *' with an lvalue of type 'BPatch_object *'
 PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);

 So obviously it's the wrong usage of the API. I am having trouble
 piecing together correct sequence of API calls for this. Appreciate your
 help.

 Cheers



 On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
 budka...@iu.edu> wrote:

> Hi Andreas,
>
> Thanks for the input. You are exactly right! :). I was looking for an
> output similar to what ldd provides. My use case is to get register usage
> patterns in a given binary and its linked shared libraries.
>
> On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng 
> wrote:
>
>> Another approach is to use BPatch_binaryEdit to open the binary,
>> which has an option parameter to specify whether also opening its
>> dependencies. Then you can convert BPatch_object to ParseAPI::CodeObject 
>> by
>> doing:
>>
>> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>>
>>
> @ Xiaozhu. I will check this out as well. Thanks!
>
>
>> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
>> wrote:
>>
>>> Hi,
>>>
>>> jumping into the conversation as I'm also doing research on shared
>>> libraries and (in a broader sense) instrumentation as part of my PhD
>>> at
>>> the University Erlangen-Nürnberg. :)
>>>
>>> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
>>> > It doesn't seem to provide the full path to the linked library,
>>> just the
>>> > library name. So when I use the return value to construct a
>>> > SymtabCodeSource it fails. Any idea how to get the full path of
>>> the
>>> > linked library?
>>> >
>>>
>>> That depends on your current system and the execution environment.
>>> If
>>> you're looking at the executable or shared library using 'readelf'
>>> (for
>>> example with the -e parameter), you see that the file itself will
>>> only
>>> specify the (file-)name of the library it requires. The actual
>>> resolution to an absolute path is done in the linker and will take
>>> default library search paths as well as the LD_LIBRARY_PATH and
>>> LD_PRELOAD environment variables into account.
>>>
>>> If you're on the system you want to analyze and want to see which
>>> libraries a given binary loads, try running 'ldd' on the binary in
>>> question, this will run the linker up to the point right before
>>> execution is handed over to the binary itself and print all imported
>>> libraries as well as their paths.
>>>
>>> I'm quite interested in what you're working on, if you'd like you
>>> can
>>> drop me a private mail.
>>>
>>> Regards,
>>>
>>> Andreas
>>>
>>>
>>> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
>>> > mailto:budka...@iu.edu>> wrote:
>>> >
>>> > Great! I will check this out.
>>> >
>>> > Cheers
>>> > Buddhika
>>> >
>>> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng <
>>> xm...@cs.wisc.edu
>>> > > wrote:
>>> >
>>> > Hi,
>>> >
>>> > If I am going to do it, I will try
>>> Symtab::getDependencies(),
>>> 

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Xiaozhu Meng
On Thu, Jan 24, 2019 at 10:05 AM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> Hi Xiaozhu,
>
> I did the following. I think I am missing something below. Can you please
> check and let me know..
>
>   BPatch* bpatch = new BPatch;
>

>   // open binary and  dependencies
>   BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);
>
>   BPatch_image* image = app->getImage();
>
>   std::vector objects;
>   image->getObjects(objects);
>
>   for (auto object : objects) {
>Dyninst::ParseAPI::CodeObject co = Dyninst::ParseAPI::convert(object);
>   }
>
> It looks like you missed a * for the CodeObject pointer declaration:

Dyninst::ParseAPI::CodeObject *** co = Dyninst::ParseAPI::convert(object);


> It fails with
>
> src/register_usage.cc:190:54: error: cannot initialize a parameter of type
> 'const BPatch_function *' with an lvalue of type 'BPatch_object *'
> PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);
>
> So obviously it's the wrong usage of the API. I am having trouble piecing
> together correct sequence of API calls for this. Appreciate your help.
>
> Cheers
>
>
>
> On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> Hi Andreas,
>>
>> Thanks for the input. You are exactly right! :). I was looking for an
>> output similar to what ldd provides. My use case is to get register usage
>> patterns in a given binary and its linked shared libraries.
>>
>> On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng  wrote:
>>
>>> Another approach is to use BPatch_binaryEdit to open the binary, which
>>> has an option parameter to specify whether also opening its dependencies.
>>> Then you can convert BPatch_object to ParseAPI::CodeObject by doing:
>>>
>>> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>>>
>>>
>> @ Xiaozhu. I will check this out as well. Thanks!
>>
>>
>>> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
>>> wrote:
>>>
 Hi,

 jumping into the conversation as I'm also doing research on shared
 libraries and (in a broader sense) instrumentation as part of my PhD at
 the University Erlangen-Nürnberg. :)

 On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
 > It doesn't seem to provide the full path to the linked library, just
 the
 > library name. So when I use the return value to construct a
 > SymtabCodeSource it fails. Any idea how to get the full path of the
 > linked library?
 >

 That depends on your current system and the execution environment. If
 you're looking at the executable or shared library using 'readelf' (for
 example with the -e parameter), you see that the file itself will only
 specify the (file-)name of the library it requires. The actual
 resolution to an absolute path is done in the linker and will take
 default library search paths as well as the LD_LIBRARY_PATH and
 LD_PRELOAD environment variables into account.

 If you're on the system you want to analyze and want to see which
 libraries a given binary loads, try running 'ldd' on the binary in
 question, this will run the linker up to the point right before
 execution is handed over to the binary itself and print all imported
 libraries as well as their paths.

 I'm quite interested in what you're working on, if you'd like you can
 drop me a private mail.

 Regards,

 Andreas


 > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
 > mailto:budka...@iu.edu>> wrote:
 >
 > Great! I will check this out.
 >
 > Cheers
 > Buddhika
 >
 > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng >>> > > wrote:
 >
 > Hi,
 >
 > If I am going to do it, I will try Symtab::getDependencies(),
 > which should return a vector of paths of the dependencies:
 >
 >
 https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
 >
 > Then, you can iterate over the vector to parse each of them.
 >
 > Thanks,
 >
 > --Xiaozhu
 >
 > On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage
 Don
 > mailto:budka...@iu.edu>> wrote:
 >
 > Hi All,
 >
 > I need to enumerate and parse linked shared libraries of a
 > binary using Symtab API and Parse API. How can I do that?
 I
 > am currently using below code sequence to parse the
 binary.
 >
 >Dyninst::SymtabAPI::Symtab* symtab;
 >bool isParsable =
 > Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
 >if (isParsable == false) {
 >  const char* error = "error: file can not be parsed";
 >  std::cout << error;
 >  

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Buddhika Chamith Kahawitage Don
Aah yes. That was a typo. My bad. However the code I tried have it correct
which still fails :(. I think the failure happens at convert function call
before the assignment.

On Thu, Jan 24, 2019 at 9:47 PM Xiaozhu Meng  wrote:

> On Thu, Jan 24, 2019 at 10:05 AM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> Hi Xiaozhu,
>>
>> I did the following. I think I am missing something below. Can you please
>> check and let me know..
>>
>>   BPatch* bpatch = new BPatch;
>>
>
>>   // open binary and  dependencies
>>   BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);
>>
>>   BPatch_image* image = app->getImage();
>>
>>   std::vector objects;
>>   image->getObjects(objects);
>>
>>   for (auto object : objects) {
>>Dyninst::ParseAPI::CodeObject co = Dyninst::ParseAPI::convert(object);
>>   }
>>
>> It looks like you missed a * for the CodeObject pointer declaration:
>
> Dyninst::ParseAPI::CodeObject *** co = Dyninst::ParseAPI::convert(object);
>
>
>> It fails with
>>
>> src/register_usage.cc:190:54: error: cannot initialize a parameter of
>> type 'const BPatch_function *' with an lvalue of type 'BPatch_object *'
>> PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);
>>
>> So obviously it's the wrong usage of the API. I am having trouble piecing
>> together correct sequence of API calls for this. Appreciate your help.
>>
>> Cheers
>>
>>
>>
>> On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
>> budka...@iu.edu> wrote:
>>
>>> Hi Andreas,
>>>
>>> Thanks for the input. You are exactly right! :). I was looking for an
>>> output similar to what ldd provides. My use case is to get register usage
>>> patterns in a given binary and its linked shared libraries.
>>>
>>> On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng  wrote:
>>>
 Another approach is to use BPatch_binaryEdit to open the binary, which
 has an option parameter to specify whether also opening its dependencies.
 Then you can convert BPatch_object to ParseAPI::CodeObject by doing:

 ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);


>>> @ Xiaozhu. I will check this out as well. Thanks!
>>>
>>>
 On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
 wrote:

> Hi,
>
> jumping into the conversation as I'm also doing research on shared
> libraries and (in a broader sense) instrumentation as part of my PhD
> at
> the University Erlangen-Nürnberg. :)
>
> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
> > It doesn't seem to provide the full path to the linked library, just
> the
> > library name. So when I use the return value to construct a
> > SymtabCodeSource it fails. Any idea how to get the full path of the
> > linked library?
> >
>
> That depends on your current system and the execution environment. If
> you're looking at the executable or shared library using 'readelf'
> (for
> example with the -e parameter), you see that the file itself will only
> specify the (file-)name of the library it requires. The actual
> resolution to an absolute path is done in the linker and will take
> default library search paths as well as the LD_LIBRARY_PATH and
> LD_PRELOAD environment variables into account.
>
> If you're on the system you want to analyze and want to see which
> libraries a given binary loads, try running 'ldd' on the binary in
> question, this will run the linker up to the point right before
> execution is handed over to the binary itself and print all imported
> libraries as well as their paths.
>
> I'm quite interested in what you're working on, if you'd like you can
> drop me a private mail.
>
> Regards,
>
> Andreas
>
>
> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
> > mailto:budka...@iu.edu>> wrote:
> >
> > Great! I will check this out.
> >
> > Cheers
> > Buddhika
> >
> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng  > > wrote:
> >
> > Hi,
> >
> > If I am going to do it, I will try Symtab::getDependencies(),
> > which should return a vector of paths of the dependencies:
> >
> >
> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
> >
> > Then, you can iterate over the vector to parse each of them.
> >
> > Thanks,
> >
> > --Xiaozhu
> >
> > On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage
> Don
> > mailto:budka...@iu.edu>> wrote:
> >
> > Hi All,
> >
> > I need to enumerate and parse linked shared libraries of
> a
> > binary using Symtab API and Parse API. How can I do
> that? I
> > am currently using below code sequence to parse the
> 

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Buddhika Chamith Kahawitage Don
By the way function PopulateUsedRegisters in the error I sent earlier
accepts a Dyninst::ParseAPI::CodeObject* as the first parameter.

On Thu, Jan 24, 2019 at 9:51 PM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> Aah yes. That was a typo. My bad. However the code I tried have it correct
> which still fails :(. I think the failure happens at convert function call
> before the assignment.
>
> On Thu, Jan 24, 2019 at 9:47 PM Xiaozhu Meng  wrote:
>
>> On Thu, Jan 24, 2019 at 10:05 AM Buddhika Chamith Kahawitage Don <
>> budka...@iu.edu> wrote:
>>
>>> Hi Xiaozhu,
>>>
>>> I did the following. I think I am missing something below. Can you
>>> please check and let me know..
>>>
>>>   BPatch* bpatch = new BPatch;
>>>
>>
>>>   // open binary and  dependencies
>>>   BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);
>>>
>>>   BPatch_image* image = app->getImage();
>>>
>>>   std::vector objects;
>>>   image->getObjects(objects);
>>>
>>>   for (auto object : objects) {
>>>Dyninst::ParseAPI::CodeObject co = Dyninst::ParseAPI::convert(object);
>>>   }
>>>
>>> It looks like you missed a * for the CodeObject pointer declaration:
>>
>> Dyninst::ParseAPI::CodeObject *** co = Dyninst::ParseAPI::convert(
>> object);
>>
>>
>>> It fails with
>>>
>>> src/register_usage.cc:190:54: error: cannot initialize a parameter of
>>> type 'const BPatch_function *' with an lvalue of type 'BPatch_object *'
>>> PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);
>>>
>>> So obviously it's the wrong usage of the API. I am having trouble
>>> piecing together correct sequence of API calls for this. Appreciate your
>>> help.
>>>
>>> Cheers
>>>
>>>
>>>
>>> On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
>>> budka...@iu.edu> wrote:
>>>
 Hi Andreas,

 Thanks for the input. You are exactly right! :). I was looking for an
 output similar to what ldd provides. My use case is to get register usage
 patterns in a given binary and its linked shared libraries.

 On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng  wrote:

> Another approach is to use BPatch_binaryEdit to open the binary, which
> has an option parameter to specify whether also opening its dependencies.
> Then you can convert BPatch_object to ParseAPI::CodeObject by doing:
>
> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>
>
 @ Xiaozhu. I will check this out as well. Thanks!


> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
> wrote:
>
>> Hi,
>>
>> jumping into the conversation as I'm also doing research on shared
>> libraries and (in a broader sense) instrumentation as part of my PhD
>> at
>> the University Erlangen-Nürnberg. :)
>>
>> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
>> > It doesn't seem to provide the full path to the linked library,
>> just the
>> > library name. So when I use the return value to construct a
>> > SymtabCodeSource it fails. Any idea how to get the full path of the
>> > linked library?
>> >
>>
>> That depends on your current system and the execution environment. If
>> you're looking at the executable or shared library using 'readelf'
>> (for
>> example with the -e parameter), you see that the file itself will
>> only
>> specify the (file-)name of the library it requires. The actual
>> resolution to an absolute path is done in the linker and will take
>> default library search paths as well as the LD_LIBRARY_PATH and
>> LD_PRELOAD environment variables into account.
>>
>> If you're on the system you want to analyze and want to see which
>> libraries a given binary loads, try running 'ldd' on the binary in
>> question, this will run the linker up to the point right before
>> execution is handed over to the binary itself and print all imported
>> libraries as well as their paths.
>>
>> I'm quite interested in what you're working on, if you'd like you can
>> drop me a private mail.
>>
>> Regards,
>>
>> Andreas
>>
>>
>> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
>> > mailto:budka...@iu.edu>> wrote:
>> >
>> > Great! I will check this out.
>> >
>> > Cheers
>> > Buddhika
>> >
>> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng <
>> xm...@cs.wisc.edu
>> > > wrote:
>> >
>> > Hi,
>> >
>> > If I am going to do it, I will try
>> Symtab::getDependencies(),
>> > which should return a vector of paths of the dependencies:
>> >
>> >
>> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
>> >
>> > Then, you can iterate over the vector to parse each of them.
>> >
>> > Thanks,
>> >
>> > --Xiaozhu
>> >
>> > 

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Buddhika Chamith Kahawitage Don
Hi Xiaozhu,

I did the following. I think I am missing something below. Can you please
check and let me know..

  BPatch* bpatch = new BPatch;

  // open binary and  dependencies
  BPatch_addressSpace* app = bpatch->openBinary(binary.c_str(), true);

  BPatch_image* image = app->getImage();

  std::vector objects;
  image->getObjects(objects);

  for (auto object : objects) {
   Dyninst::ParseAPI::CodeObject co = Dyninst::ParseAPI::convert(object);
  }

It fails with

src/register_usage.cc:190:54: error: cannot initialize a parameter of type
'const BPatch_function *' with an lvalue of type 'BPatch_object *'
PopulateUsedRegisters(Dyninst::ParseAPI::convert(object), used);

So obviously it's the wrong usage of the API. I am having trouble piecing
together correct sequence of API calls for this. Appreciate your help.

Cheers



On Thu, Jan 24, 2019 at 8:53 PM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> Hi Andreas,
>
> Thanks for the input. You are exactly right! :). I was looking for an
> output similar to what ldd provides. My use case is to get register usage
> patterns in a given binary and its linked shared libraries.
>
> On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng  wrote:
>
>> Another approach is to use BPatch_binaryEdit to open the binary, which
>> has an option parameter to specify whether also opening its dependencies.
>> Then you can convert BPatch_object to ParseAPI::CodeObject by doing:
>>
>> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>>
>>
> @ Xiaozhu. I will check this out as well. Thanks!
>
>
>> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler 
>> wrote:
>>
>>> Hi,
>>>
>>> jumping into the conversation as I'm also doing research on shared
>>> libraries and (in a broader sense) instrumentation as part of my PhD at
>>> the University Erlangen-Nürnberg. :)
>>>
>>> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
>>> > It doesn't seem to provide the full path to the linked library, just
>>> the
>>> > library name. So when I use the return value to construct a
>>> > SymtabCodeSource it fails. Any idea how to get the full path of the
>>> > linked library?
>>> >
>>>
>>> That depends on your current system and the execution environment. If
>>> you're looking at the executable or shared library using 'readelf' (for
>>> example with the -e parameter), you see that the file itself will only
>>> specify the (file-)name of the library it requires. The actual
>>> resolution to an absolute path is done in the linker and will take
>>> default library search paths as well as the LD_LIBRARY_PATH and
>>> LD_PRELOAD environment variables into account.
>>>
>>> If you're on the system you want to analyze and want to see which
>>> libraries a given binary loads, try running 'ldd' on the binary in
>>> question, this will run the linker up to the point right before
>>> execution is handed over to the binary itself and print all imported
>>> libraries as well as their paths.
>>>
>>> I'm quite interested in what you're working on, if you'd like you can
>>> drop me a private mail.
>>>
>>> Regards,
>>>
>>> Andreas
>>>
>>>
>>> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
>>> > mailto:budka...@iu.edu>> wrote:
>>> >
>>> > Great! I will check this out.
>>> >
>>> > Cheers
>>> > Buddhika
>>> >
>>> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng >> > > wrote:
>>> >
>>> > Hi,
>>> >
>>> > If I am going to do it, I will try Symtab::getDependencies(),
>>> > which should return a vector of paths of the dependencies:
>>> >
>>> >
>>> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
>>> >
>>> > Then, you can iterate over the vector to parse each of them.
>>> >
>>> > Thanks,
>>> >
>>> > --Xiaozhu
>>> >
>>> > On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage
>>> Don
>>> > mailto:budka...@iu.edu>> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I need to enumerate and parse linked shared libraries of a
>>> > binary using Symtab API and Parse API. How can I do that? I
>>> > am currently using below code sequence to parse the binary.
>>> >
>>> >Dyninst::SymtabAPI::Symtab* symtab;
>>> >bool isParsable =
>>> > Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
>>> >if (isParsable == false) {
>>> >  const char* error = "error: file can not be parsed";
>>> >  std::cout << error;
>>> >  return;
>>> >}
>>> >
>>> >// Create a new binary code object from the filename
>>> argument
>>> >Dyninst::ParseAPI::SymtabCodeSource* sts =
>>> >new
>>> Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
>>> >Dyninst::ParseAPI::CodeObject* co = new
>>> > Dyninst::ParseAPI::CodeObject(sts);
>>> >

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Buddhika Chamith Kahawitage Don
Hi Andreas,

Thanks for the input. You are exactly right! :). I was looking for an
output similar to what ldd provides. My use case is to get register usage
patterns in a given binary and its linked shared libraries.

On Thu, Jan 24, 2019 at 7:24 PM Xiaozhu Meng  wrote:

> Another approach is to use BPatch_binaryEdit to open the binary, which has
> an option parameter to specify whether also opening its dependencies. Then
> you can convert BPatch_object to ParseAPI::CodeObject by doing:
>
> ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);
>
>
@ Xiaozhu. I will check this out as well. Thanks!


> On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler  wrote:
>
>> Hi,
>>
>> jumping into the conversation as I'm also doing research on shared
>> libraries and (in a broader sense) instrumentation as part of my PhD at
>> the University Erlangen-Nürnberg. :)
>>
>> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
>> > It doesn't seem to provide the full path to the linked library, just
>> the
>> > library name. So when I use the return value to construct a
>> > SymtabCodeSource it fails. Any idea how to get the full path of the
>> > linked library?
>> >
>>
>> That depends on your current system and the execution environment. If
>> you're looking at the executable or shared library using 'readelf' (for
>> example with the -e parameter), you see that the file itself will only
>> specify the (file-)name of the library it requires. The actual
>> resolution to an absolute path is done in the linker and will take
>> default library search paths as well as the LD_LIBRARY_PATH and
>> LD_PRELOAD environment variables into account.
>>
>> If you're on the system you want to analyze and want to see which
>> libraries a given binary loads, try running 'ldd' on the binary in
>> question, this will run the linker up to the point right before
>> execution is handed over to the binary itself and print all imported
>> libraries as well as their paths.
>>
>> I'm quite interested in what you're working on, if you'd like you can
>> drop me a private mail.
>>
>> Regards,
>>
>> Andreas
>>
>>
>> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
>> > mailto:budka...@iu.edu>> wrote:
>> >
>> > Great! I will check this out.
>> >
>> > Cheers
>> > Buddhika
>> >
>> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng > > > wrote:
>> >
>> > Hi,
>> >
>> > If I am going to do it, I will try Symtab::getDependencies(),
>> > which should return a vector of paths of the dependencies:
>> >
>> >
>> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
>> >
>> > Then, you can iterate over the vector to parse each of them.
>> >
>> > Thanks,
>> >
>> > --Xiaozhu
>> >
>> > On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don
>> > mailto:budka...@iu.edu>> wrote:
>> >
>> > Hi All,
>> >
>> > I need to enumerate and parse linked shared libraries of a
>> > binary using Symtab API and Parse API. How can I do that? I
>> > am currently using below code sequence to parse the binary.
>> >
>> >Dyninst::SymtabAPI::Symtab* symtab;
>> >bool isParsable =
>> > Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
>> >if (isParsable == false) {
>> >  const char* error = "error: file can not be parsed";
>> >  std::cout << error;
>> >  return;
>> >}
>> >
>> >// Create a new binary code object from the filename
>> argument
>> >Dyninst::ParseAPI::SymtabCodeSource* sts =
>> >new
>> Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
>> >Dyninst::ParseAPI::CodeObject* co = new
>> > Dyninst::ParseAPI::CodeObject(sts);
>> >co->parse();
>> >
>> >auto fit = co->funcs().begin();
>> >for (; fit != co->funcs().end(); ++fit) {
>> >  Dyninst::ParseAPI::Function* f = *fit;
>> >  
>> >}
>> >
>> > Regards
>> > Buddhika
>> > ___
>> > Dyninst-api mailing list
>> > Dyninst-api@cs.wisc.edu 
>> > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>> >
>> >
>> > ___
>> > Dyninst-api mailing list
>> > Dyninst-api@cs.wisc.edu
>> > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>> >
>>
>
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-24 Thread Xiaozhu Meng
Another approach is to use BPatch_binaryEdit to open the binary, which has
an option parameter to specify whether also opening its dependencies. Then
you can convert BPatch_object to ParseAPI::CodeObject by doing:

ParseAPI::CodeObject *ParseAPI::convert(BPatch_object *);

On Thu, Jan 24, 2019 at 1:36 AM Andreas Ziegler  wrote:

> Hi,
>
> jumping into the conversation as I'm also doing research on shared
> libraries and (in a broader sense) instrumentation as part of my PhD at
> the University Erlangen-Nürnberg. :)
>
> On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
> > It doesn't seem to provide the full path to the linked library, just the
> > library name. So when I use the return value to construct a
> > SymtabCodeSource it fails. Any idea how to get the full path of the
> > linked library?
> >
>
> That depends on your current system and the execution environment. If
> you're looking at the executable or shared library using 'readelf' (for
> example with the -e parameter), you see that the file itself will only
> specify the (file-)name of the library it requires. The actual
> resolution to an absolute path is done in the linker and will take
> default library search paths as well as the LD_LIBRARY_PATH and
> LD_PRELOAD environment variables into account.
>
> If you're on the system you want to analyze and want to see which
> libraries a given binary loads, try running 'ldd' on the binary in
> question, this will run the linker up to the point right before
> execution is handed over to the binary itself and print all imported
> libraries as well as their paths.
>
> I'm quite interested in what you're working on, if you'd like you can
> drop me a private mail.
>
> Regards,
>
> Andreas
>
>
> > On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don
> > mailto:budka...@iu.edu>> wrote:
> >
> > Great! I will check this out.
> >
> > Cheers
> > Buddhika
> >
> > On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng  > > wrote:
> >
> > Hi,
> >
> > If I am going to do it, I will try Symtab::getDependencies(),
> > which should return a vector of paths of the dependencies:
> >
> >
> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
> >
> > Then, you can iterate over the vector to parse each of them.
> >
> > Thanks,
> >
> > --Xiaozhu
> >
> > On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don
> > mailto:budka...@iu.edu>> wrote:
> >
> > Hi All,
> >
> > I need to enumerate and parse linked shared libraries of a
> > binary using Symtab API and Parse API. How can I do that? I
> > am currently using below code sequence to parse the binary.
> >
> >Dyninst::SymtabAPI::Symtab* symtab;
> >bool isParsable =
> > Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
> >if (isParsable == false) {
> >  const char* error = "error: file can not be parsed";
> >  std::cout << error;
> >  return;
> >}
> >
> >// Create a new binary code object from the filename
> argument
> >Dyninst::ParseAPI::SymtabCodeSource* sts =
> >new
> Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
> >Dyninst::ParseAPI::CodeObject* co = new
> > Dyninst::ParseAPI::CodeObject(sts);
> >co->parse();
> >
> >auto fit = co->funcs().begin();
> >for (; fit != co->funcs().end(); ++fit) {
> >  Dyninst::ParseAPI::Function* f = *fit;
> >  
> >}
> >
> > Regards
> > Buddhika
> > ___
> > Dyninst-api mailing list
> > Dyninst-api@cs.wisc.edu 
> > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
> >
> >
> > ___
> > Dyninst-api mailing list
> > Dyninst-api@cs.wisc.edu
> > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
> >
>
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-23 Thread Andreas Ziegler

Hi,

jumping into the conversation as I'm also doing research on shared 
libraries and (in a broader sense) instrumentation as part of my PhD at 
the University Erlangen-Nürnberg. :)


On 1/24/19 4:18 AM, Buddhika Chamith Kahawitage Don wrote:
It doesn't seem to provide the full path to the linked library, just the 
library name. So when I use the return value to construct a 
SymtabCodeSource it fails. Any idea how to get the full path of the 
linked library?




That depends on your current system and the execution environment. If 
you're looking at the executable or shared library using 'readelf' (for 
example with the -e parameter), you see that the file itself will only 
specify the (file-)name of the library it requires. The actual 
resolution to an absolute path is done in the linker and will take 
default library search paths as well as the LD_LIBRARY_PATH and 
LD_PRELOAD environment variables into account.


If you're on the system you want to analyze and want to see which 
libraries a given binary loads, try running 'ldd' on the binary in 
question, this will run the linker up to the point right before 
execution is handed over to the binary itself and print all imported 
libraries as well as their paths.


I'm quite interested in what you're working on, if you'd like you can 
drop me a private mail.


Regards,

Andreas


On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don 
mailto:budka...@iu.edu>> wrote:


Great! I will check this out.

Cheers
Buddhika

On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng mailto:xm...@cs.wisc.edu>> wrote:

Hi,

If I am going to do it, I will try Symtab::getDependencies(),
which should return a vector of paths of the dependencies:

https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366

Then, you can iterate over the vector to parse each of them.

Thanks,

--Xiaozhu

On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don
mailto:budka...@iu.edu>> wrote:

Hi All,

I need to enumerate and parse linked shared libraries of a
binary using Symtab API and Parse API. How can I do that? I
am currently using below code sequence to parse the binary.

   Dyninst::SymtabAPI::Symtab* symtab;
   bool isParsable =
Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
   if (isParsable == false) {
     const char* error = "error: file can not be parsed";
     std::cout << error;
     return;
   }

   // Create a new binary code object from the filename argument
   Dyninst::ParseAPI::SymtabCodeSource* sts =
   new Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
   Dyninst::ParseAPI::CodeObject* co = new
Dyninst::ParseAPI::CodeObject(sts);
   co->parse();

   auto fit = co->funcs().begin();
   for (; fit != co->funcs().end(); ++fit) {
     Dyninst::ParseAPI::Function* f = *fit;
     
   }

Regards
Buddhika
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu 
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api


___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api


___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-23 Thread Buddhika Chamith Kahawitage Don
It doesn't seem to provide the full path to the linked library, just the
library name. So when I use the return value to construct a
SymtabCodeSource it fails. Any idea how to get the full path of the linked
library?

On Wed, Jan 23, 2019 at 10:20 PM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> Great! I will check this out.
>
> Cheers
> Buddhika
>
> On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng  wrote:
>
>> Hi,
>>
>> If I am going to do it, I will try Symtab::getDependencies(), which
>> should return a vector of paths of the dependencies:
>>
>> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
>>
>> Then, you can iterate over the vector to parse each of them.
>>
>> Thanks,
>>
>> --Xiaozhu
>>
>> On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don <
>> budka...@iu.edu> wrote:
>>
>>> Hi All,
>>>
>>> I need to enumerate and parse linked shared libraries of a binary using
>>> Symtab API and Parse API. How can I do that? I am currently using below
>>> code sequence to parse the binary.
>>>
>>>   Dyninst::SymtabAPI::Symtab* symtab;
>>>   bool isParsable = Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
>>>   if (isParsable == false) {
>>> const char* error = "error: file can not be parsed";
>>> std::cout << error;
>>> return;
>>>   }
>>>
>>>   // Create a new binary code object from the filename argument
>>>   Dyninst::ParseAPI::SymtabCodeSource* sts =
>>>   new Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
>>>   Dyninst::ParseAPI::CodeObject* co = new
>>> Dyninst::ParseAPI::CodeObject(sts);
>>>   co->parse();
>>>
>>>   auto fit = co->funcs().begin();
>>>   for (; fit != co->funcs().end(); ++fit) {
>>> Dyninst::ParseAPI::Function* f = *fit;
>>> 
>>>   }
>>>
>>> Regards
>>> Buddhika
>>> ___
>>> Dyninst-api mailing list
>>> Dyninst-api@cs.wisc.edu
>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
>>
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-23 Thread Buddhika Chamith Kahawitage Don
Great! I will check this out.

Cheers
Buddhika

On Wed, Jan 23, 2019 at 10:01 PM Xiaozhu Meng  wrote:

> Hi,
>
> If I am going to do it, I will try Symtab::getDependencies(), which should
> return a vector of paths of the dependencies:
>
> https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366
>
> Then, you can iterate over the vector to parse each of them.
>
> Thanks,
>
> --Xiaozhu
>
> On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don <
> budka...@iu.edu> wrote:
>
>> Hi All,
>>
>> I need to enumerate and parse linked shared libraries of a binary using
>> Symtab API and Parse API. How can I do that? I am currently using below
>> code sequence to parse the binary.
>>
>>   Dyninst::SymtabAPI::Symtab* symtab;
>>   bool isParsable = Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
>>   if (isParsable == false) {
>> const char* error = "error: file can not be parsed";
>> std::cout << error;
>> return;
>>   }
>>
>>   // Create a new binary code object from the filename argument
>>   Dyninst::ParseAPI::SymtabCodeSource* sts =
>>   new Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
>>   Dyninst::ParseAPI::CodeObject* co = new
>> Dyninst::ParseAPI::CodeObject(sts);
>>   co->parse();
>>
>>   auto fit = co->funcs().begin();
>>   for (; fit != co->funcs().end(); ++fit) {
>> Dyninst::ParseAPI::Function* f = *fit;
>> 
>>   }
>>
>> Regards
>> Buddhika
>> ___
>> Dyninst-api mailing list
>> Dyninst-api@cs.wisc.edu
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>
>
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] Enumerating linked shared libraries with SymtabAPI/ ParseAPI

2019-01-23 Thread Xiaozhu Meng
Hi,

If I am going to do it, I will try Symtab::getDependencies(), which should
return a vector of paths of the dependencies:

https://github.com/dyninst/dyninst/blob/master/symtabAPI/h/Symtab.h#L366

Then, you can iterate over the vector to parse each of them.

Thanks,

--Xiaozhu

On Wed, Jan 23, 2019 at 10:20 AM Buddhika Chamith Kahawitage Don <
budka...@iu.edu> wrote:

> Hi All,
>
> I need to enumerate and parse linked shared libraries of a binary using
> Symtab API and Parse API. How can I do that? I am currently using below
> code sequence to parse the binary.
>
>   Dyninst::SymtabAPI::Symtab* symtab;
>   bool isParsable = Dyninst::SymtabAPI::Symtab::openFile(symtab, binary);
>   if (isParsable == false) {
> const char* error = "error: file can not be parsed";
> std::cout << error;
> return;
>   }
>
>   // Create a new binary code object from the filename argument
>   Dyninst::ParseAPI::SymtabCodeSource* sts =
>   new Dyninst::ParseAPI::SymtabCodeSource(binary.c_str());
>   Dyninst::ParseAPI::CodeObject* co = new
> Dyninst::ParseAPI::CodeObject(sts);
>   co->parse();
>
>   auto fit = co->funcs().begin();
>   for (; fit != co->funcs().end(); ++fit) {
> Dyninst::ParseAPI::Function* f = *fit;
> 
>   }
>
> Regards
> Buddhika
> ___
> Dyninst-api mailing list
> Dyninst-api@cs.wisc.edu
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api