Implement plugin subsystem

[fogInSingularity]

Implement plugin subsystem:

Plugin subsystem consist of following parts:

Plugin manager(that manages plugins and notify them on events)
Plugin(manages dynamically loaded plugin)
loadPlugin function that returns LoadablePlugin struct with pointers to notify, unload and plugin internal memory.

I need help deciding on the notify function signature. I think it’s worth making a function for each event (due to the fact that the parameters will be different for different events).

[derzhavin3016]

I suggest you to implement PluginAPI as an interface class to avoid C-style type erasure void * and simplify plugin usage. Interface can consist of two virtual function for loading plugin (which will somehow subscribe plugin on some events) and unloading for unsubscribtion.

[fogInSingularity]

I changed the implementation of the plugin subsystem:

Now you need to inherit from IPlugin to create your own plugin and supply function IPlugin* loadPlugin(const char* options) that allocates your plugin.

But i this code currently have bug

hsim::SharedLib sharedLib{"./path/to/libconcrete_plugin.so", hsim::kLazy};

auto plugin = hsim::loadPluginFromSO(sharedLib, "option");
machine.addEventConsumer(std::move(plugin));
machine.notify();

~SharedLib called before ~IPlugin(that calls ~ConcretePlugin that is loaded from .so file) so there a use after free
im not sure how to fix it

[fogInSingularity]

I fixed use after free bug
current plugin subsystem:

[derzhavin3016]

In general, design looks nice to me (seems like an Observer pattern). But there is some noticeable point about extensibility: events list could be extended & each event can accept different arguments (types & amount). Also, you need to somehow distinguish events with identical call signatures (e.g. memwrite & memread events arguments would be the same)

[derzhavin3016]

For example, try to define two events with identical argument list, and two events with different arguments list. Hope this helps to prototype generic solution

[derzhavin3016]

Example event notification (approximate syntax):

event_model.call<MemWrite>(core, ptr, size);

[derzhavin3016]

Some comments, it's not required to be fixed since they're absolutely minor. It's more like a notice

[derzhavin3016]

AFAIK, it is not required by standard

[derzhavin3016]

I'm confused a bit with thus function. How could you remove plugin by address, if you've lost it after attach() call?
e.g.:

EventManager ev;
auto consumer = std::make_unique<IntConsumer>(42);
ev.attach(std::move(consumer));
// consumer is in moved-from state hereafter
ev.detach(???); // what to pass here?

[fogInSingularity]

I'm confused a bit with thus function. How could you remove plugin by address, if you've lost it after attach() call? e.g.:

EventManager ev;
auto consumer = std::make_unique<IntConsumer>(42);
ev.attach(std::move(consumer));
// consumer is in moved-from state hereafter
ev.detach(???); // what to pass here?

is detach necessary at all?

[derzhavin3016]

Let's remove this method

[derzhavin3016]

After personal discussion, it was decided to leave implementation in current state, with optional code deduplication via defines/Jinja codegen.

The last part is to add Unit tests, after which this PR could be merged