On 19 Nov 13:00, Richard Biener wrote: > On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law <l...@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.enkov...@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 > >
