[llvm-dev] [cfe-dev] [GSOC 2018] Information gathering

Paul Semel via llvm-dev
2018-03-06T16:24:16Z

Hi,

Thanks for replying !

On 03/02/2018 10:58 PM, Artem Dergachev wrote:
> 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.
>

So.. I uploaded the checker on Phabricator !
Please keep in mind that it was for me a proof of concept, and I didn't
have in mind to purpose this patch at the time I was developping it (and
didn't have the time to improve it for the moment, as I am currently
working on a structure pretty printing builtin -
https://reviews.llvm.org/D44093).

For the moment, this checker is not able to detect all the unsequenced
modifications, but can detect things like this :

```c
static int a = 0;

int foo(void)
{
   return a++;
}

int main(void)
{
   int res = a++ + foo();
   return res;
}
```

So here is the link on Phabricator : https://reviews.llvm.org/D44154

> 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.
>

Sure, I would really like to have some other info on this one ! Maybe
you know someone I could had in cc of this thread ? 🙂

> 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).
>

Ok I think that I understand the idea. So the idea is that this checker
will be an API that will permit to track those invariants (and we will
use this API to track str.c_str()).
Am I right ?

> 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.
>
>

Wow. This project sounds really cool, it's really too bad that there is
already two students on this project.

>
> 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,
>>
>

By the way, if you have some free time, I would really appreciate to
have some advices on a better way to do the unsequenced modification
checker. 🙂


Thanks,

--
Paul Semel