On 04/16/14 08:03, Ilya Enkovich wrote:
Hi,

This patch introduces changes in call graph for Pointer Bounds Checker.

New fields instrumented_version, instrumentation_clone and orig_decl are added 
for cgraph_node:
  - instrumentation_clone field is 1 for nodes created for instrumented version 
of functions
  - instrumented_version points to instrumented/original node
  - orig_decl holds original function declaration for instrumented nodes in 
case original node is removed

IPA_REF_CHKP reference type is introduced for nodes to reference instrumented 
function versions from originals.  It is used to have proper reachability 
analysis.

When original function bodies are not needed anymore, functions are transformed 
into thunks having call edge to the instrumented function.  Therefore new field 
appeared in cgraph_thunk_info to mark such thunks.

Does it look OK?

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-04-16  Ilya Enkovich  <ilya.enkov...@intel.com>

        * cgraph.h (cgraph_thunk_info): Add add_pointer_bounds_args
        field.
        (cgraph_node): Add instrumented_version, orig_decl and
        instrumentation_clone fields.
        (symtab_alias_target): Allow IPA_REF_CHKP reference.
        * cgraph.c (cgraph_remove_node): Fix instrumented_version
        of the referenced node if any.
        (dump_cgraph_node): Dump instrumentation_clone and
        instrumented_version fields.
        (verify_cgraph_node): Check correctness of IPA_REF_CHKP
        references and instrumentation thunks.
        * cgraphbuild.c (rebuild_cgraph_edges): Rebuild IPA_REF_CHKP
        reference.
        (cgraph_rebuild_references): Likewise.
        * cgraphunit.c (assemble_thunks_and_aliases): Skip thunks
        calling instrumneted function version.
        * ipa-ref.h (ipa_ref_use): Add IPA_REF_CHKP.
        (ipa_ref): increase size of use field.
        * ipa-ref.c (ipa_ref_use_name): Add element for IPA_REF_CHKP.
        * lto-cgraph.c (lto_output_node): Output instrumentation_clone,
        thunk.add_pointer_bounds_args and orig_decl field.
        (lto_output_ref): Adjust to new ipa_ref::use field size.
        (input_overwrite_node): Read instrumentation_clone field.
        (input_node): Read thunk.add_pointer_bounds_args and orig_decl
        fields.
        (input_ref): Adjust to new ipa_ref::use field size.
        (input_cgraph_1): Compute instrumented_version fields and restore
        IDENTIFIER_TRANSPARENT_ALIAS chains.
        * lto-streamer.h (LTO_minor_version): Change minor version from
        0 to 1.
        * ipa.c (symtab_remove_unreachable_nodes): Consider instrumented
        clone as address taken if the original one is address taken.
        (cgraph_externally_visible_p): Mark instrumented 'main' as
        externally visible.
        (function_and_variable_visibility): Filter instrumentation
        thunks.


diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index be3661a..6210c68 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2850,7 +2861,9 @@ verify_cgraph_node (struct cgraph_node *node)
        }
        for (i = 0; ipa_ref_list_reference_iterate (&node->ref_list,
                                                  i, ref); i++)
-       if (ref->use != IPA_REF_ALIAS)
+       if (ref->use == IPA_REF_CHKP)
+         ;
+       else if (ref->use != IPA_REF_ALIAS)
          {
            error ("Alias has non-alias reference");
            error_found = true;
Is there any checking you can/should be doing here? And I'm asking because I'm pretty sure there's something you ought to be checking here :-)

There's a general desire for key datastructures to sanity check them as much as possible.

+  /* If instrumentation_clone is 1 then instrumented_version points
+     to the original function used to make instrumented version.
+     Otherwise points to instrumented version of the function.  */
+  struct cgraph_node *instrumented_version;
+  /* If instrumentation_clone is 1 then orig_decl is the original
+     function declaration.  */
+  tree orig_decl;
So I don't see anything which checks these two invariants.

Mostly it looks good. I do want to look at it again once the verification stuff is beefed up.


Jeff

Reply via email to