Actions
Feature #2159
closedA step to a general purpose C AOP implementation
Start date:
01/05/2012
Due date:
% Done:
0%
Estimated time:
Published in build:
Description
I'm thinking how can we avoid complex manipulations with cc and ld commands performing in rule-instrumentor. This is required to avoid multiple definitions of symbols (these symbols describe model functions and state). Briefly speaking, at the moment for each cc command both "state" (i.e. including model functions and state) and "non-state" files are obtained. In linking for a final target just one "state" file is taken, while others are "non-state".
Unfortunatelly, this assumes that one should implement something similar to rule-instrumentor cc and ld command manipulations for a general use case of "aspectator" to allow usage of common functions and state. I consider this as a big drawback of our appoach. I found out a workaround for the given problem. We can use option allow-multiple-definition for linker:
So, I assume the following use case:
Unfortunatelly, this assumes that one should implement something similar to rule-instrumentor cc and ld command manipulations for a general use case of "aspectator" to allow usage of common functions and state. I consider this as a big drawback of our appoach. I found out a workaround for the given problem. We can use option allow-multiple-definition for linker:
--allow-multiple-definition
-z muldefs
Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions and the first definition will be used.
So, I assume the following use case:
- User develops an aspect that contains both relations with sources and common functions and state.
- Instead of a default compiler user uses "aspectator" to build just "state" files (in most cases these files will be object files).
- Then user links obtained files together by means of "aspectator" that is used also instead of the default compiler. "Aspectator" just adds option "_-Xlinker --allow-multiple-definition_" to gcc on this stage. May be user also should modify CC_FLAGS or/and LD_FLAGS.
As for LDV the last stage isn't performed at all now. But as Pavel has said, CIL can merge the same symbols (I also checked this by myself). That's why there should be no problems. Moreover we'll significantly simplify and speed up rule-instrumentor, in particular caching.
Any ideas?
Actions