On Fri, Jan 22, 2021 at 9:32 PM David Malcolm <dmalc...@redhat.com> wrote: > > On Fri, 2021-01-22 at 20:46 +0530, Adharsh Kamath wrote: > > Hi David. Thank you for the reply. > > On Tue, Jan 19, 2021 at 2:12 AM David Malcolm <dmalc...@redhat.com> > > wrote: > > > On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote: > > > > Hello, > > > > I came across the list of possible project ideas for GSoC 2021 > > > > and > > > > I'd > > > > like to contribute to the project regarding the static analysis > > > > pass > > > > in GCC. > > > > How can I get started with this project? > > > > > > Hi Adharsh > > > > > > Sorry about the delay in responding to your email. > > > > > > Thanks for your interest in the static analysis pass. > > > > > > Some ideas on getting started with GCC are here: > > > https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply > > > > > > The analyzer has its own wiki page here: > > > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > > > I examined the analyzer dumps for a few programs. I also read the > > documentation on the internals of > > the static analyzer and I've understood the basics of how the > > analyzer works. > > Excellent. Building GCC from source and stepping through it in the > debugger would be good next steps. You'll need plenty of disk space. > "run_checkers" is a good breakpoint to set if you're looking for the > entrypoint to the analyzer.
Yes, I'll try this. > > > I've actually already implemented some of the ideas that were on > > > the > > > GSoC wiki page myself since last summer, so I've updated that page > > > accordingly: > > > > > > https://gcc.gnu.org/wiki/SummerOfCode?action=diff&rev2=187&rev1=184 > > > I've added the idea of SARIF ( https://sarifweb.azurewebsites.net/ > > > ) as > > > an output format for the static analyzer (and indeed, for the GCC > > > diagnostics subsystem as a whole). > > > > > > Do any of the ideas on the page look appealing to you? I'm open to > > > other ideas you may have relating to the analyzer, or indeed to gcc > > > diagnostics. > > > > Yes. Making a plugin for the Linux kernel seems very interesting to > > me. > > I'd also like to extend support for C++ but I'm not sure if both > > ideas would be > > possible, given the time constraints. > > I think that picking just one would be better than trying to do both. > > > How do I start with the plugin for > > the Linux kernel? > > I added plugin support to the analyzer in: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825 > > There's an example plugin in that patch. The kernel source tree > already has some plugins, so hopefully those together give some > pointers on how to write a "hello world" analyzer plugin that runs as > part of the kernel build, which would be another next step, I guess. I will go through the plugin in the kernel source tree and try to write a simple analyzer plugin. > Unfortunately I'm not a Linux kernel developer, so I don't have deep > knowledge of what checks would be useful and the subtle details that > are likely to be necessary. I'll try to reach out internally within > Red Hat - we have plenty of kernel developers here. > > Some ideas: > * detecting code paths that acquire a lock but then fail to release it > * detecting code paths that disable interrupts and then fail to re- > enable them > * detecting mixups between user-space pointers and kernel-space > pointers > > The kernel has its own checker called "smatch" which may give other > ideas for warnings. > > The state machine checker in the analyzer takes its inspiration from > the Stanford "MC" checker (among other places, such as typestate), > which has been used to implement warnings for the Linux kernel, albeit > some very old versions of the kernel. > > See:: > * "How to write system-specific, static checkers in Metal" (Benjamin > Chelf, Dawson R Engler, Seth Hallem), from 2002 > * "Checking system rules using system-specific, programmer-written > compiler extensions" Proceedings of Operating Systems Design and > Implementation (OSDI), September 2000. D. Engler, B. Chelf, A. Chou, > and S. Hallem. > * "Using Programmer-Written Compiler Extensions to Catch Security > Holes" (Ken Ashcraft, Dawson Engler) from 2002 > > These are working on 20-year-old in-kernel APIs that might be obsolete > now, but they have examples of interrupt checking, and user-space vs > kernel-space pointer checking. > > Focusing on error-handling paths in driver code might be best. > > Does this answer your questions? Yes. Thank you very much for these resources. I will go through them. Adharsh
