Hi,
I have a way of extracting the macro arguments from the Smatch.
My idea is to extend the `store_macro_pos()` in `macro_table.c` and
delay its invocation in `pre-process.c` AFTER the arguments have been
expanded.
So, we can have a list of argument tokens that were passed into that macro.
The changes are moderate.
1. Add struct macro { struct token* t; struct token_list *arg_list... };
2. Extend `store_macro_pos(struct token* token)` ->
`store_macro_pos(struct token* token, struct token_list* args)`.
3. Delay the invocation inside `pre-process` and pass an expanded list
of arguments when saving a macro.
4. Change the logic and naming in `macro_table.c`
What do you think about this feature? Would it be useful in the mainline?
Perhaps I can open a PR later.
Hongyi LU
Best.
Dan Carpenter <[email protected]> 于2024年6月21日周五 03:57写道：
>
> On Thu, Jun 20, 2024 at 05:39:04PM +0300, Dan Carpenter wrote:
> > On Thu, Jun 20, 2024 at 10:12:28PM +0800, Hongyi Lu wrote:
> > > Oh, may I ask how to do that with Smatch?
> > >
> >
> > See the attached file and test file. The output should be:
> >
> > test.c:13 function() call: frob() state=[check_conditions] x & 1 (nil) =
> > 'merged' [merged] (false, true, merged)
> > test.c:16 function() call: frob() state=[check_conditions] x & 1 (nil) =
> > 'true'
> >
> > Except instead of 'x' you'd want some way to tie that back to the input
> > from the user.
>
> One of the things that Smatch saves is that value of variables in
> smatch_extra.c. So maybe instead of saving conditions you just want to
> save the values of variables. "x = 0-15" range when we call frob().
>
> We also track values which the user controls.
>
> Or we could say (struct foo)->member_name which comes from the user is
> in 0-15 range when we call frob().
>
> An earlier student group looked at system calls which referenced the
> same (struct foo)->member_name and tried to race them against each other
> in syzkaller. They did find some bugs that way.
>
> regards,
> dan carpenter
>
