This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support


On 19 Nov 13:00, Richard Biener wrote:
> On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law <law@redhat.com> wrote:
> > On 11/08/13 02:02, Ilya Enkovich wrote:
> >>
> >> Hi,
> >>
> >> Here is an updated patch version with no langhook.
> >>
> >> Regarding TLS objects issue - I do not think compiler should compensate
> >> the absence of instrumentation in libraries.  Compiler should be responsible
> >> for initialization of Bounds Tables for .tdata section.  Correct data copy
> >> is a responsibility of library.  User should use either instrumented library
> >> or wrapper calls if he needs this functionality.
> >>
> >> Thanks,
> >> Ilya
> >> --
> >> gcc/
> >>
> >> 2013-11-06  Ilya Enkovich  <ilya.enkovich@intel.com>
> >>
> >>         * c/c-parser.c: Include tree-chkp.h.
> >>         (c_parser_declaration_or_fndef): Register statically
> >>         initialized decls in Pointer Bounds Checker.
> >>         * cp/decl.c: Include tree-chkp.h.
> >>         (cp_finish_decl): Register statically
> >>         initialized decls in Pointer Bounds Checker.
> >>         * gimplify.c: Include tree-chkp.h.
> >>         (gimplify_init_constructor): Register statically
> >>         initialized decls in Pointer Bounds Checker.
> >
> > Is parsing really the right time to register these things with the checking
> > framework?  Doesn't all this stuff flow through the gimplifier?  If so
> > wouldn't that be a better place?
> >
> > If it can be done in the gimplifier, which seems good from the standpoint of
> > simplifying the long term maintenance of the checking code.
> >
> > If there's a good reason to have this front-end, please explain it.
> 
> I'd say not in the gimplifier either but in varpool (symbol table) code
> where the symbols are ultimatively registered with?

Something like that?

--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl)
   node = varpool_create_empty_node ();
   node->decl = decl;
   symtab_register_node (node);
+
+  if (DECL_NIITIAL (decl))
+    chkp_register_var_initializer (decl);
+
   return node;
 }

Thanks,
Ilya

> 
> Richard.
> 
> > Thanks,
> > Jeff
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]