Actions
Feature #3802
closedAdd ability to refer to function argument by its name specified in aspect file
Start date:
12/14/2012
Due date:
% Done:
0%
Estimated time:
Published in build:
24ff9f3
Description
Often it may be helpful to refer to a function argument by its name specified in an aspect file. I mean, that we would like to write something like:
pointcut KALLOC: execution(static inline void *kcalloc(.., gfp_t flags, ..)
|| call(void * krealloc(.., gfp_t flags, ..))
...
|| call(int pskb_expand_head(.., gfp_t flags, ..))
|| call(struct sk_buff *skb_copy_expand(.., gfp_t flags, ..))
...
and then refer in corresponding advice bodies to flags instead of separating this pointcut to several ones in depend on the gft_t argument place:
pointcut ARG_3: execution(static inline void *kcalloc(..))
|| call(void * krealloc(..))
...
pointcut ARG_4: call(int pskb_expand_head(..))
|| call(struct sk_buff *skb_copy_expand(..))
...
and creating multiple advices referring to $argi for each of ARG_i pointcuts.
BTW, there is a special mechanism in, say, AspectJ and ACC, that is referred as "pointcut parameters". With help of it we will be able to shorten KALLOC pointcut definition:
pointcut KALLOC(flags): (execution(static inline void *kcalloc(..)
|| call(void * krealloc(..))
...
|| call(int pskb_expand_head(..))
|| call(struct sk_buff *skb_copy_expand(..))
...)
&& args(.., gfp_t flags, ..)
Although this notation as well as its "full" variant doesn't take care on parameter place, that may be important in some cases. To do this we either should use such the pointcut (it looks too expensive :)):
pointcut KALLOC: execution(static inline void *kcalloc($, $, gfp_t flags, ..)
|| call(void * krealloc($, $, gfp_t flags, ..))
...
|| call(int pskb_expand_head($, $, $, gfp_t flags, ..))
|| call(struct sk_buff *skb_copy_expand($, $, $, gfp_t flags, ..))
...
or something like this:
pointcut KALLOC: execution(static inline void *kcalloc(..<2>, gfp_t flags, ..)
|| call(void * krealloc(..<2>, gfp_t flags, ..))
...
|| call(int pskb_expand_head(..<3>, gfp_t flags, ..))
|| call(struct sk_buff *skb_copy_expand(..<3>, gfp_t flags, ..))
...
One more task is to combine together function calls that have flags and that haven't them (GFP_KERNEL is implied implicitly):
pointcut KALLOC: execution(static inline void *kcalloc(..<2>, gfp_t flags, ..)
|| call(void * krealloc(..<2>, gfp_t flags, ..))
...
|| call(int pskb_expand_head(..<3>, gfp_t flags, ..))
|| call(struct sk_buff *skb_copy_expand(..<3>, gfp_t flags, ..))
...
|| call(void *vmalloc(..))
But this case we should be able to write in advice body something like:
ldv_check_flags($defined<flags,GFP_KERNEL>);
may be it exceeds formalization requirements, since it may be easier and clearer to write a separate binding and a separate model function for memory allocation functions without flags.
Files
Actions