This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, Pointer Bounds Checker 14/x] Passes [4/n] Memory accesses instrumentation
- From: Jeff Law <law at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 13 Oct 2014 14:52:31 -0600
- Subject: Re: [PATCH, Pointer Bounds Checker 14/x] Passes [4/n] Memory accesses instrumentation
- Authentication-results: sourceware.org; auth=none
- References: <20141008190138 dot GD13454 at msticlxl57 dot ims dot intel dot com>
On 10/08/14 13:01, Ilya Enkovich wrote:
This is the main chunk of instrumentation codes. This patch introduces instrumentation pass which instruments memory accesses.
2014-10-08 Ilya Enkovich<email@example.com>
* tree-chkp.c (chkp_may_complete_phi_bounds): New.
@@ -491,6 +910,129 @@ chkp_get_bounds_var (tree ptr_var)
+/* Register bounds BND for object PTR in global bounds table.
+ A copy of bounds may be created for abnormal ssa names.
+ Returns bounds to use for PTR. */
+chkp_maybe_copy_and_register_bounds (tree ptr, tree bnd)
+ bool abnormal_ptr;
+ if (!chkp_reg_bounds)
+ return bnd;
+ /* Do nothing if bounds are incomplete_bounds
+ because it means bounds will be recomputed. */
+ if (bnd == incomplete_bounds)
+ return bnd;
+ abnormal_ptr = (TREE_CODE (ptr) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ptr)
+ && gimple_code (SSA_NAME_DEF_STMT (ptr)) != GIMPLE_PHI);
+ /* A single bounds value may be reused multiple times for
+ different pointer values. It may cause coalescing issues
+ for abnormal SSA names. To avoid it we create a bounds
+ copy in case it is copmputed for abnormal SSA name.
+ if (!bounds)
Are you just looking for the parameter in which we pass the static
chain? Look at get_chain_decl for how we set it up. You may actually
have to peek at more fields. I don't think there's a single magic bit
that says "this is the static chain". Though it may always appear in
the same location on the parameter list. Nested functions aren't
something I'd poked with much. Richard Henderson might know more since
he wrote tree-nested a while back.
+ tree orig_decl = cgraph_node::get (cfun->decl)->orig_decl;
+ /* For static chain param we return zero bounds
+ because currently we do not check dereferences
+ of this pointer. */
+ /* ?? Is it a correct way to identify such parm? */
+ if (cfun->decl && DECL_STATIC_CHAIN (cfun->decl)
+ && DECL_ARTIFICIAL (decl))
+ bounds = chkp_get_zero_bounds ();
Ugh. Note how this introduces another place that anyone who might add a
new RHS gimple statement needs to edit. We need a pointer back to this
code so that folks will know it needs updating. The question is where
to put it.
@@ -1107,6 +1821,323 @@ chkp_build_bndstx (tree addr, tree ptr, tree bounds,
+/* Compute bounds for pointer NODE which was assigned in
+ assignment statement ASSIGN. Return computed bounds. */
+chkp_compute_bounds_for_assignment (tree node, gimple assign)
Basically we want a place where anyone adding a new code that can appear
on the RHS of an assignment must change already. Thoughts on a good
I realize there's probably many other places that probably need these
kinds of documentation back links, I'm not asking you to address all of
+/* Compute and returne bounds for address of OBJ. */
Presumably none of the code you're inserting that causes these problems
is ever supposed to be executed on the non-fallthru edge? Else your
"creative" method of hiding the abnormal nature of the edge for a period
of time, then recreating it won't work.
+/* Some code transformation made during instrumentation pass
+ may put code into inconsistent state. Here we find and fix
+ such flaws. */
I'm a bit worried by this code and while I'll approve it, it's something
we may have to come back and revisit if it causes problems.
So I think there's a couple typo nits to fix and one backlink doc issue
to address and possibly a tweak to the code to identify static chains.
With those fixed this should be good to go onto the trunk.