Re: [PATCH] -fsanitize=vptr instrumentation (take 2)

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Dec 01, 2014 at 09:45:30AM -0500, Jason Merrill wrote:
> On 11/28/2014 09:41 AM, Jakub Jelinek wrote:
> >>Why do you look through ARRAY_REF here?  An element of an array is its own
> >>complete object.
> >
> >That had to do with only instrumenting dereferences surrounded by handled
> >components, but not accesses to decls (so p->x gets instrumented but
> >q.x for VAR_DECL q is not).
> 
> That also seems like an optimization we decided we don't want; we know what
> type q was declared as, but its vptr might have gotten clobbered by code
> with undefined behavior.

One more question.  My current version of the patch adds one ubsan vptr
instrumentation in each of the following functions:

struct S { int s; virtual void foo (); S(); virtual ~S(); };
struct T : S {};
struct U { int u; S s[4]; };
struct V { U v; virtual void bar (); V(); virtual ~V(); };
V v;

int
f1 (V *p)
{
  return p->v.u;
}

int
f2 (V *p)
{
  return p->v.s[2].s;
}

int
f3 ()
{
  return v.v.u;
}

int
f4 ()
{
  return v.v.s[2].s;
}

(in f1 and f3 verifies it for _ZTI1V, in f2 and f4 verifies it for
_ZTI1S).  Should I change it so that we get 2 instrumentations in f2 and f4
and one in f1/f3 (i.e. in f2/f4 check two vptrs, one _ZTI1S and one _ZTI1V),
or do we care just about the outermost one?
Note, latest clang has 1 instrumentation in f1 and f4, two in f2 and none
in f3.  I think we've agreed we want to instrument even normal decl member
accesses and method calls.

	Jakub