Hi Dan, Thank you very much, this helps greatly! And no worries for delayed reply, I have not gotten to resolve this yet, was busy with other things. Let me try this out! Best Regards, Elena. > -----Original Message----- > From: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > Sent: Monday, September 13, 2021 6:10 PM > To: Reshetova, Elena <elena.reshetova@xxxxxxxxx> > Cc: smatch@xxxxxxxxxxxxxxx > Subject: Re: BKM on generating a call graph for smatch warnings > > Hi, > > I'm really sorry, I missed your email. I was on vacation that week and > didn't see your email until now. > > On Tue, Aug 17, 2021 at 07:32:21AM +0000, Reshetova, Elena wrote: > > Hi, > > > > Quick question: are there some suggested methods for obtaining a call graph > > for a warning that a smatch pattern reports when I run it for the whole kernel? > > > > I can see that there are a couple of existing patterns (check_capable, > check_locking) > > that use sql methods for saving the caller_info, but I don't fully understand how it > > works, maybe there is some description somewhere on this that I missed? > > How the Smatch cross function database works is that you run: > > /path/to/smatch/smatch_scripts/build_kernel_data.sh > > This takes a long time to run. It does a complete Smatch run and it > outputs a ton of SQL insert commands. Then it does: > > cat sql.txt | sqlite3 smatch_db.sqlite > > It doesn't literally cat that because that would be very slow. It's > uses a perl script to handle transactions, caching and syncing etc. > There is also a little bit of tweaking for some of the tables. The > final database on my system is 30GB. > > What I do is I rebuild my database every night. Each time you rebuild > the database then the knowledge about the call tree gets pushed out one > call further. > > In my experience if you rebuild the DB 5-7 times, that's basically > the limit. The call tree is complete, of course, right away. foo() > calls bar() calls baz(). But it takes two rebuilds before the user > data from foo() gets to baz(). > > The /path/to/smatch/smatch_data/db/smdb.py script is a way to see what's > stored in the database. `smdb.py foo` will print all the callers of > foo() and `smdb.py return_states foo` will show what it returns. > > Again, very sorry for the long delay. Please let me know if you have > any questions. > > regards, > dan carpenter
