Hi,
just a quick question: Is it possible to create a new opaque type for
Bro using a dynamic plugin without touching Bro sources?
Best regards,
Jan
Yes, it should. I believe if you implement the logic in your plugin's
InitPreScript() method, it should work.
Robin
Is it possible to create a new opaque type for Bro using a dynamic
plugin without touching Bro sources?Yes, it should. I believe if you implement the logic in your plugin's
InitPreScript() method, it should work.
Meanwhile I gave it a try: I implemented a class inheriting from
OpaqueVal and declared a global OpaqueType variable as extern. I
initialized the type variable inside InitPreScript(). That compiled just
fine but executing Bro failed due to dynamic linking issues
(c++ - What happens to global and static variables in a shared library when it is dynamically linked? - Stack Overflow seems to explain that). I
circumvented this issue by using a static variable (= limited scope)
that I initialized in place. This went well and the new opaque value
seems to behave as expected. However, I wonder if I am missing anything
that might cause problems?
One thing I am aware of is that I did not declare the value type as
serializable. I think that is not needed for my use case. Besides it
would require to define a corresponding identifier (see SerialTypes.h),
whose uniqueness cannot be guaranteed for a plugin, right?
Best regards
Jan
that I initialized in place. This went well and the new opaque value
seems to behave as expected. However, I wonder if I am missing anything
that might cause problems?
Mind sharing your code (both before/after the change, and also the
error message you got)?
One thing I am aware of is that I did not declare the value type as
serializable.
Yeah, fine as long as you don't try to send it around or store on disk.
Besides it would require to define a corresponding identifier (see
SerialTypes.h), whose uniqueness cannot be guaranteed for a plugin,
right?
Yeah, good point, there's no mechanism for that.
Robin
that I initialized in place. This went well and the new opaque value
seems to behave as expected. However, I wonder if I am missing anything
that might cause problems?Mind sharing your code (both before/after the change, and also the
error message you got)?
Sure. The code is available at
https://github.com/J-Gras/bro-plugins/tree/topic/jgras/liblognorm/liblognorm.
Unfortunately I don't have commits for both versions but the changes are
minimal. The relevant files are src/LogNormalizer*.
Currently LogNormalizer.cc:11 declares the type using static. That seems
to work (as it is local). If I remove "static" and use the "extern"
declaration commented in LogNormalizer.h:78 (like its done in Bro),
loading the plugin fails with:
fatal error in /home/jgras/devel/bro/scripts/base/init-bare.bro, line 1:
cannot load plugin library
/home/jgras/devel/bro/aux/plugins/liblognorm/build//lib/Bro-Lognorm.linux-x86_64.so:
/home/jgras/devel/bro/aux/plugins/liblognorm/build//lib/Bro-Lognorm.linux-x86_64.so:
undefined symbol: _ZN6plugin11Bro_Lognorm18lognormalizer_typeE
From what I understand this is expected as a dynamically linked global
variable would need special treatment. But as I am not used to C++ and
my understanding of Bro's type system is limited, I am not sure I missed
important details in my solution.
Best regards,
Jan
Took me a bit to look at this, but I've tried it now. My guess is that
it was a namespace issue. Look at the attached patch, that version
works for me.
That said, your version using "static" is completely fine. Indeed,
it's even the better one for the plugin case: defining it globally
non-static is useful only if other object files need to access it.
Inside your plugin, that's not the case; and outside the plugin nobody
can (because nobody can rely on the plugin being present). So I think
your solution is just fine.
Good to see you got the type working from a plugin. Would be even
nicer if Bro actually showed the new type in the output of "-NN" but
we don't have the support in place yet for a plugin to register it
accordingly.
Robin
jan (859 Bytes)
Took me a bit to look at this, but I've tried it now. My guess is that
it was a namespace issue. Look at the attached patch, that version
works for me.
Thanks a lot for taking a look! I missed that "using" does not do the
trick for a definition. I guess its time to read a C++ book 
That said, your version using "static" is completely fine. Indeed,
it's even the better one for the plugin case: defining it globally
non-static is useful only if other object files need to access it.
Inside your plugin, that's not the case; and outside the plugin nobody
can (because nobody can rely on the plugin being present). So I think
your solution is just fine.
I am happy to hear that this is a proper solution. My fear was that I
was missing a mechanism, which announces the type to Bro. My thought was
that in this case the limited visibility might become an issue.
Big thanks for your support!
Jan