Powered by Linux
Re: Treat macro call like ordinary functions in smatch. — Semantic Matching Tool

Re: Treat macro call like ordinary functions in smatch.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <dan.carpenter@xxxxxxxxxx> 于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
>





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux