[panda-users] problems with plugin api calls

[Leek, Timothy - 0559 - MITLL]

HI Manolis.  If I understand correctly, you are having trouble b/c your
plugin B is composed of multiple .c / .cpp files.  Yes?  I think that isn¹t
something we considered.  So, yes, a bug of sorts.

We tend to write small plugins or are content to have the code all squished
into a single file.  And then we compose the plugins.   For instance, the
tainted_instructions plugin is very small.  And useless on its own (since
nothing ever gets labeled).  But paired with file_taint or tstringsearch +
string search, it can do something.   One solution would be to conceive of
your analysis as distributed across a few plugins.

Or I think it would all work if you just sure that that code that needs the
other plugin¹s functionality is limited to one source file in your plugin.
  
Ok, this makes it sound like we designed things this way.  That¹s not true.
I, at least, was aware of this issue/limitation but didn¹t consider it worth
the extra software engineering.  So, yes, we are lazy and prefer using PANDA
to software engineering it.  Sorry!

I don¹t have a solution ready at hand for your problem, but we will think
about it.  You got any ideas that aren¹t too ugly or painful?

--
Tim Leek
Technical Staff
Cyber System Assessments
MIT Lincoln Laboratory
781-981-2975


From:  Manolis Stamatogiannakis <mstamat at gmail.com>
Date:  Sunday, April 19, 2015 at 7:19 PM
To:  "panda-users at mit.edu" <panda-users at mit.edu>
Subject:  Re: [panda-users] problems with plugin api calls

Ok, this looks like a bug in the way the plugin calls are implemented.

In pluginA_ext.h, the symbol used to point to the api call is defined as:
static api_call_t __api_call = NULL;

Because the symbol is static, it will be re-defined within *every* module
that includes pluginA_ext.h.
However, in the example I described only the symbol in pluginB.cpp will be
initialized.
The symbol in pluginB_module.cpp will remain NULL.

Could someone propose some clean way around this limitation?

I quickly checked that if I change the definition in the _ext header to an
"extern" declaration and move the definition in pluginB.cpp the calls
succeed. But this is just a quick&dirty hack to verify the problem, as it
involves manually editing the _ext file.

Thanks,
Manolis







2015-04-19 15:56 GMT-07:00 Manolis Stamatogiannakis <mstamat at gmail.com>:
> I'm having problems with using the plugin api to make calls across plugins. Is
> there an implicit assumption that plugins should consist of a single file?
> 
> Here are the steps I make:
> (1) define the function in pluginA_int_fns.h
> (2) include this header in pluginA_int.h
> (3) implement the function in pluginA.cpp
>  
> (4) include generated pluginA_ext.h from pluginB.cpp
> (5) call init_pluginA_api() without problems
> (6) include generated pluginA_ext.h from pluginB_module.cpp
> (7) make the API call from within pluginB_module.cpp
> 
> Everything compiles fine, but at runtime I hit the assertion error in the
> function definition in pluginA_ext.h.
> I added some printfs and __api_call is not NULL just after init_pluginA_api()
> in pluginB.cpp. However, it is NULL inside pluginB_module.cpp.
> 
> Any ideas how could that happen? Am I missing something in the picture?
> 
> Thanks,
> Manolis
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/panda-users/attachments/20150420/83245921/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3076 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150420/83245921/attachment.bin