This change adds a simple plugin architecture to asan_symbolize.py.
The motivation here is that sometimes it's necessary to perform extra
work to figure out where binaries with debug symbols can actually be
found. For example it might be the case that a remote service needs
to be queried for binaries and then copied to the local system.
This "extra work" can be extremely site-specific such that adding the
code directly into the asan_symbolize.py would just clutter the code
for a very niche use case. To avoid this, the asan_symbolize.py can
now load external code via a new --plugins command line option.
These plugins are loaded before main command line argument parsing so
that they can add their own command line options.
Right now the only hook into the behaviour of symbolization is the
filter_binary_path() function which assumes a very similar role
to the binary_name_filter function that was previously in the code.
We can add more hooks as necessary.
Code in the asan_symbolize.py script does not call plugin code
directly. Instead it uses a AsanSymbolizerPlugInProxy object.
This object
- Loads plugins from files.
- Manages the lifetime of the plugins.
- Provides an interface for calling into plugin functions and handles calling into multiple plugins.
To unify the way binary paths are filtered the old sysroot_path_filter
function (and associated code) has been turned into a simple plugin
(SysRootFilterPlugIn) that is always loaded. The plugin unloads
itself if the -s option is not present on the command line. Users
should not see any functional change relating to this command line
option.
Some simple tests are provided to illustrate what plugin code looks
like and also to check the functionality continues to work.
rdar://problem/49476995
why do you need to extract -s into plugin?