Feature #2159
closedA step to a general purpose C AOP implementation
0%
Description
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?
Updated by Alexey Khoroshilov over 12 years ago
This is reasonable and it makes sense to measure speed up of the simplified rule-instrumentor. But as soon as it depends on capabilities of RCV, we have to support both variants.
Updated by Evgeny Novikov over 12 years ago
Alexey Khoroshilov wrote:
This is reasonable and it makes sense to measure speed up of the simplified rule-instrumentor. But as soon as it depends on capabilities of RCV, we have to support both variants.
Yes... In fact, this complex manipulations were inherited from old llvm based mode (at that time it was necessary, because linking was performed actually). I'm not sure that we should keep this backward compatibility (i.e. support llvm), so, we can, nevertheless, obtain all "state" files but in linking performed in rule-instrumentor (not in gcc-aspectator) we'll drop "state" from all files except one. This'll simplify and speed up rule-instrumentor in any case, but also this'll require some primitive fixes of "aspectator" and rule-instrumentor.
Updated by Evgeny Novikov almost 12 years ago
As for general purpose C AOP implementation, that approach doesn't depend on RCV capabilities with comparison with the approach suggested here. And it is more flexible because of program developers should determine how to process common functions and variables by themselves. Developers should:
- specify a file, where to place them, by means of a special environment variable
- provide an additional CC comand with proper options for this file compilation
- link obtained object code with other program objects to make common functions and variables available
In case of LDV this work is automatically performed by Rule Instrumentor (compilation options are obtained from a first CC command of module compilation).
Updated by Evgeny Novikov over 11 years ago
- Project changed from Linux Driver Verification to C Instrumentation Framework
- Category deleted (
15)
Updated by Evgeny Novikov over 11 years ago
- Status changed from Open to Closed
Because of #453 feature request has implemented a step to a general purpose C AOP implementation, I marked this feature request as a duplicate of that one.