<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-04-20 6:05 GMT-07:00 Leek, Timothy - 0559 - MITLL <span dir="ltr">&lt;<a href="mailto:tleek@ll.mit.edu" target="_blank">tleek@ll.mit.edu</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div><div>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.  </div></div></div></blockquote><div><br></div><div>Yes, this is the case. Thanks for confirming.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div>  </div><div>Ok, this makes it sound like we <span style="font-weight:bold">designed</span> 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!</div><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div><br>I understand this is an oversight (nobody needed this until now) rather than a design decision.<br><br>I was able to overcome the problem by also making the inlines inside the auto-generated header static. This way they operate on the source-file-specific instance of the static function pointer variable. See: <a href="https://github.com/m000/panda/commit/5b6573274f34ea9f368b7da88272c035f238dcd4">https://github.com/m000/panda/commit/5b6573274f34ea9f368b7da88272c035f238dcd4</a><br>Each source-file is still responsible to seperately initialize any APIs it uses. But this wouldn&#39;t be much of a problem as PANDA plugins don&#39;t usually grow big.<br></div><div>This is not very ugly (I think) and shoulnd&#39;t affect the operation of other plugins in the pipeline (mine is: osi;osi_linux;other_plugin). If this looks ok, you can cherry-pick the commit. Or I can make a pull request later.<br></div><div><br></div><div>A &quot;better&quot; fix (from the engineering perspective :)) would involve (a) Changing the static function pointers definition to extern declarations. (b) Generating an additional header with the definitions of the externs. The header would have to be included by the &quot;main&quot; module of the plugin. But I would agree with you that this is probably too much engineering for something that is not the common case in PANDA&#39;s usage.<br></div><div><br></div>Cheers,<br></div><div class="gmail_quote">Manolis<br></div><br></div></div>