On 5/30/19 11:23 AM, Jason Merrill wrote:
> On Thu, May 30, 2019 at 12:16 PM Jeff Law <l...@redhat.com> wrote:
>>
>> On 5/30/19 9:34 AM, Martin Sebor wrote:
>>
>>>>> If the alias oracle can be used to give the same results without
>>>>> excessive false positives then I think it would be fine to make
>>>>> use of it. Is that something you consider a prerequisite for
>>>>> this change or should I look into it as a followup?
>>>> I think we should explore it a bit before making a final decision. It
>>>> may guide us for other work in this space (like detecting escaping
>>>> locals). I think a dirty prototype to see if it's even in the right
>>>> ballpark would make sense.
>>>
>>> Okay, let me look into it.
>> Sounds good. Again, go with a quick prototype to see if it's likely
>> feasible. The tests you've added should dramatically help evaluating if
>> the oracle is up to the task.
>>
>>>
>>>>> FWIW, I'm working on enhancing this to detect returning freed
>>>>> pointers (under a different option). That seems like a good
>>>>> opportunity to also look into making use of the alias oracle.
>>>> Yes. I think there's two interesting cases here to ponder. If we free
>>>> a pointer that must point to a local, then we can warn & trap. If we
>>>> free a pointer that may point to a local, then we can only warn (unless
>>>> we can isolate the path).
>>>
>>> I wasn't actually thinking of freeing locals but it sounds like
>>> a useful enhancement as well. Thanks for the suggestion! :)
>>>
>>> To be clear, what I'm working on is detecting:
>>>
>>> void* f (void *p)
>>> {
>>> free (p); // note: pointer was freed here
>>> // ...
>>> return p; // warning: returning a freed pointer
>>> }
>> Ah, we were talking about different things. Though what you're doing
>> might be better modeled in a true global static analyzer as a
>> use-after-free problem. My sense is that translation-unit local version
>> of that problem really isn't that useful in practice. THough I guess
>> there isn't anything bad with having a TU local version.
>>
>>
>>>
>>>>> Besides these enhancements, there's also a request to diagnose
>>>>> dereferencing pointers to compound literals whose lifetime has
>>>>> ended (PR 89990), or more generally, those to any such local
>>>>> object. It's about preventing essentially the same problem
>>>>> (accessing bad data or corrupting others) but it seems that
>>>>> both the analysis and the handling will be sufficiently
>>>>> different to consider implementing it somewhere else. What
>>>>> are your thoughts on that?
>>>> I think the tough problem here is we lose binding scopes as we lower
>>>> into gimple, so solving it in the general case may be tough. We've
>>>> started adding some clobbers into the IL to denote object death points,
>>>> but I'm not sure if they're sufficient to implement this kind of warning.
>>>
>>> I was afraid that might be a problem.
>> Way back in the early days of tree-ssa we kept the binding scopes. But
>> that proved problematical in various ways. Mostly they just got in the
>> way of analysis an optimization and we spent far too much time in the
>> optimizers working around them or removing those which were empty.
>>
>> They'd be helpful in this kind of analysis, stack slot sharing vs the
>> inliner and a couple other problems. I don't know if the pendulum has
>> moved far enough to revisit :-)
>
> Why wouldn't clobbers be sufficient?
I haven't looked into the clobbers in any detail. If we're aggressively
emitting them at the end of object life, then they may be sufficient to
start tackling these issues.
jeff
