Paul Semel via llvm-dev
2018-Feb-20 22:51 UTC
[llvm-dev] [GSOC 2018] Information gathering
Hello, I'm Paul Semel, a French student in computer science. I am currently in my 4th year (1st year of graduate school) at EPITA and enrolled in the system and security laboratory of the school. I would be very interested in working on a LLVM project during this GSoC. Implementing a PoC for an unsequenced modification checker in CSA helped me discover LLVM. However, I would like to dive deeper in this project. I've seen some of the proposals, and I would like to ask a few questions about two of those. As you might have guessed, I have some interest in the checker for dangling string pointers : - Do you think it would help if I kept working on improving my unsequenced modification checker to get more familiar with Clang Static Analyzer ? I'm also interested in the command line replacements for GNU Binutils : - What tools would you like to replace in priority ? - Does this subject imply to add options/features to some of the tools, or is it only about handling command line ? Thank you very much, -- Paul Semel
Paul Semel via llvm-dev
2018-Mar-01 19:43 UTC
[llvm-dev] [cfe-dev] [GSOC 2018] Information gathering
Hey, On 02/20/2018 11:51 PM, Paul Semel wrote:> Hello, > > > I'm Paul Semel, a French student in computer science. I am currently in > my 4th year (1st year of graduate school) at EPITA and enrolled in the > system and security laboratory of the school. > > I would be very interested in working on a LLVM project during this > GSoC. Implementing a PoC for an unsequenced modification checker in CSA > helped me discover LLVM. However, I would like to dive deeper in this > project. > > I've seen some of the proposals, and I would like to ask a few questions > about two of those. > > As you might have guessed, I have some interest in the checker for > dangling string pointers : > > - Do you think it would help if I kept working on improving my > unsequenced modification checker to get more familiar with Clang Static > Analyzer ? > > I'm also interested in the command line replacements for GNU Binutils : > > - What tools would you like to replace in priority ? > - Does this subject imply to add options/features to some of the tools, > or is it only about handling command line ? > > Thank you very much, > >Adding cfe-dev.. Regards, -- Paul Semel
Artem Dergachev via llvm-dev
2018-Mar-02 21:58 UTC
[llvm-dev] [cfe-dev] [GSOC 2018] Information gathering
Hey, welcome! I'm curious about the unsequenced modification checker, is it something that I should have seen but missed for whatever reason? It might be useful, and I think I'm seeing why don't compiler warnings cover all cases, i.e. why the analyzer's path sensitivity would help here. But I can't answer until I see it :) -eg. on our Phabricator. We are currently having two confirmed mentors for the Analyzer for now (me and George), so we'd most likely be able to mentor one student each, for two projects, and it'd likely be the two projects we proposed - unless someone proposes something really interesting. And already two fairly motivated students have shown up here in the mailing lists, but this shouldn't stop you from posting your own proposal here in cfe-dev (most of the analyzer contributors aren't actively scanning llvm-dev, as far as I know). I don't know much about the binutils replacement project; someone else should reply on that one. A couple of words about the use-after-free-like checker for values managed by temporary objects (mostly strings) that go out of scope. Because internals of std::string and other similar classes are too hard for the analyzer's generic use-after-free checker to understand (mostly due to how hard it is to track STL's internal invariants, and how not all of the code is necessarily present in the header), an API-specific checker seems to be necessary. The original plan we've had in mind was to keep track of dangerous values like str.c_str() in the program state (similarly to how SimpleStreamChecker tracks file descriptors) and then see if any of them are still present in memory at the end of the original value's lifetime (similarly to how StackAddrEscape checker finds stack pointers at the end of a function's stack frame). The unknowns here include how easy would it be to track scopes (for now we only track function scopes, but if fairly old but recently reincarnated patches [1] and [2] land any time soon, we may get a much better granularity), how easy would it be to track objects when they are moved or lifetime-extended by binding to references, which was a large problem for other C++ object checkers, but we may work our way around it to some extent (or do it properly, depending on my current work outlined in [3] and in follow-up mails in February), and also how helpful inlining would be (eg. would we be able to automagically support string_view-like classes by inlining their methods?). So the checker would need an almost indefinite amount of incremental improvements once the initial prototype is done, some of which must be fairly curious and would certainly expose you to some of the analyzer's internals. On 01/03/2018 11:43 AM, Paul Semel via cfe-dev wrote:> Hey, > > On 02/20/2018 11:51 PM, Paul Semel wrote: >> Hello, >> >> >> I'm Paul Semel, a French student in computer science. I am currently >> in my 4th year (1st year of graduate school) at EPITA and enrolled in >> the system and security laboratory of the school. >> >> I would be very interested in working on a LLVM project during this >> GSoC. Implementing a PoC for an unsequenced modification checker in >> CSA helped me discover LLVM. However, I would like to dive deeper in >> this project. >> >> I've seen some of the proposals, and I would like to ask a few >> questions about two of those. >> >> As you might have guessed, I have some interest in the checker for >> dangling string pointers : >> >> - Do you think it would help if I kept working on improving my >> unsequenced modification checker to get more familiar with Clang >> Static Analyzer ? >> >> I'm also interested in the command line replacements for GNU Binutils : >> >> - What tools would you like to replace in priority ? >> - Does this subject imply to add options/features to some of the >> tools, or is it only about handling command line ? >> >> Thank you very much, >> >> > > Adding cfe-dev.. > > Regards, >
Paul Semel via llvm-dev
2018-Mar-08 09:29 UTC
[llvm-dev] [cfe-dev] [GSOC 2018] Information gathering
Hi Eric, As you are pointed to be the confirmed mentor for the "Command line replacements for GNU Binutils" GSOC 2018 subject, I permit myself to add you to this thread ! If you have a few minutes to answer my questions, that'd really great 🙂 On 03/01/2018 08:43 PM, Paul Semel wrote:> Hey, > > On 02/20/2018 11:51 PM, Paul Semel wrote: >> Hello, >> >> >> I'm Paul Semel, a French student in computer science. I am currently >> in my 4th year (1st year of graduate school) at EPITA and enrolled in >> the system and security laboratory of the school. >> >> I would be very interested in working on a LLVM project during this >> GSoC. Implementing a PoC for an unsequenced modification checker in >> CSA helped me discover LLVM. However, I would like to dive deeper in >> this project. >> >> I've seen some of the proposals, and I would like to ask a few >> questions about two of those. >> >> As you might have guessed, I have some interest in the checker for >> dangling string pointers : >> >> - Do you think it would help if I kept working on improving my >> unsequenced modification checker to get more familiar with Clang >> Static Analyzer ? >> >> I'm also interested in the command line replacements for GNU Binutils : >> >> - What tools would you like to replace in priority ? >> - Does this subject imply to add options/features to some of the >> tools, or is it only about handling command line ? >> >> Thank you very much, >> >> > > Adding cfe-dev.. > > Regards, >Thanks, -- Paul Semel