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?
Jaason
