The most important tables are caller_info and return_states which are mirror images. One is the states when the function is called. The other is the states when the function returns. smatch_data/db/caller_info.schema file caller => function calling function => function called call_id => a different id means a different function call static => is it static type => type of information in the database parameter key value smatch_data/db/return_states.schema file function call_id => this is used for inline functions with the in-memory db. return_id => we split the return states up as much as possible return => return ranges static => is it static type => type of information parameter key value I have been meaning to rename return_states to return_info for some time... The next most important table is the call_implies table. This basically means we grouped all the paths through the function together and <whatever> is true. It can mean that we dereference a parameter. Or it can mean we use a $0->foo->bar from parameter 0. All the columns are the same as for return_states.schema. smatch_data/db/function_ptr.schema This is a link with function pointers and the functions that implement them. All the other tables are to do with linking data types with their possible values or buffer sizes. These tables are a bit of a mess. function_type_info has raw data that's useful for if you want to see where a value is set, type_info is useful for smatch to look up the data quickly. There is actually a lot of really great data in the database, but the smdb.py program is horribly primitive. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
