Add plugin activity log file functionality #588
Conversation
quic-seaswara
left a comment
quic-seaswara
left a comment
There was a problem hiding this comment.
This is going in the right direction.
It would be useful to combine just not the activity of adding and removing chunks, we might need linker state records and also the various operations it tries to invoke via the LinkerWrapper.
Can we also generate one file per plugin ?
partaror
force-pushed
the
PrimitivePluginActLog
branch
from
a088a55 to
bcff6f5
Compare
parth-07
force-pushed
the
PrimitivePluginActLog
branch
from
bcff6f5 to
dd570ce
Compare
Yes, totally agreed. This PR only adds the primitive framework for recording and printing the JSON file. Follow-up patches will extend the support for more relevant plugin operations.
I do not think we should generate plugin actions per plugin as we plan to add a utility tool that users can use to filter plugin activities of a particular plugin. Please let me know your thoughts on this. |
parth-07
force-pushed
the
PrimitivePluginActLog
branch
from
dd570ce to
d79d8c7
Compare
quic-seaswara
left a comment
quic-seaswara
left a comment
There was a problem hiding this comment.
As usual, pls document :)
A script to read the JSON log file will be useful.
| Group<grp_mapopts>; | ||
|
|
||
| defm PluginActivityFile | ||
| : smDashWithOpt<"plugin-activity-file", "PluginActivityFile", |
There was a problem hiding this comment.
plugin-activity-log ? can we create a seperate category for plugins ? This is housed under map file options or diagnostics, can it be moved ?
There was a problem hiding this comment.
Thank you for mentioning this. Yes, I will move it to a different category. I will need to see which category would fit best for it.
I previously used the name --plugin-activity-log but later changed it to --plugin-activity-file as the latter makes it clear that the input argument would be a filename. What do you think about it?
There was a problem hiding this comment.
I have moved this option to the grp_pluginopts.
Can we please document this once the functionality is close to complete? This PR only adds primitive support of this feature. |
parth-07
force-pushed
the
PrimitivePluginActLog
branch
3 times, most recently
from
3c950f7 to
193d0c9
Compare
| PLUGIN_ACT-DAG: "Annotation": "", | ||
| PLUGIN_ACT-DAG: "Fragment": "{{.*}}1.o(.text.foo2)", | ||
| PLUGIN_ACT-DAG: "Plugin": "OutSectIterPluginActLog", | ||
| PLUGIN_ACT-DAG: "Rule": "*(.text.foo*) #Rule 1, {{.*}}script.t", |
There was a problem hiding this comment.
Can we have the Rule that contains only rule strings ?
Since it is a data structure now compared to text, probably adding
RuleID :
InputFile:
There was a problem hiding this comment.
Can we make this more modular / structured when the need arises? I feel that more modular structure here can increase the work without necessarily giving the benefits.
I plan to add a --filter option to the tool that will read the plugin activity file. Users can use it as ELDPluginRunAnalyzer plugin.activity.json --filter "/a/b/c/1.o" to find all the plugin actions that contains the filename /a/b/c/1.o.
The filter option will work by simply seeing if the JSON structure of the rule matches the filter-word. Thus, it can be used
to find relevant plugin operations without having individual fields for things such as input file.
partaror
force-pushed
the
PrimitivePluginActLog
branch
from
193d0c9 to
ddb164f
Compare
parth-07
force-pushed
the
PrimitivePluginActLog
branch
from
ddb164f to
d400a49
Compare
partaror
force-pushed
the
PrimitivePluginActLog
branch
from
d400a49 to
2f44045
Compare
This commit adds primitive support for plugin activity log file functionality. It adds the option '--plugin-activity-log <file>' to the linker. With this option, the linker emits a JSON plugin activity log file that contains the ordered records of relevent plugin actions for later analysis and debugging. Currently, only the following operations are fully supported: RemoveSymbol, UpdateChunks, and updateLinkStat. The support for remaining operations will be added in follow-up patches. One key difference between the plugin operation information in the map-file and the plugin activity log file is that in the map-file, the plugin operations are separated as per operation type and the plugin. On the other hand, in the plugin activity log file, we have a single array of the operations by all the plugins. This allows to determine the total ordering of the operations that can be important for various analysis. Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
partaror
force-pushed
the
PrimitivePluginActLog
branch
from
2f44045 to
cc80ad7
Compare
2 participants
This commit adds primitive support for plugin activity log file functionality.
It adds the option '--plugin-activity-log ' to the linker. With this option,
the linker emits a JSON plugin activity log file that contains the
ordered records of relevent plugin actions for later analysis and debugging. Currently,
only the following operations are fully supported: RemoveSymbol, UpdateChunks,
and updateLinkStat. The support for remaining operations will be added
in follow-up patches.
One key difference between the plugin operation information in the map-file
and the plugin activity log file is that in the map-file, the plugin
operations are separated as per operation type and the plugin. On the
other hand, in the plugin activity log file, we have a single array of
the operations by all the plugins. This allows to determine the total
ordering of the operations that can be important for various analysis.