Re: [PATCH, Pointer Bounds Checker 14/x] Passes [4/n] Memory accesses instrumentation

[Jeff Law <law at redhat dot com>]

On 10/14/14 04:08, Ilya Enkovich wrote:
> > 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.
>
> Looking through tree-nested.c I found there is a static_chain_decl in
> function structure holding created decl.
Perfect.


> > 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.
> >
> > 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 location?
> >
> > 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 them.
>
> Actually it shouldn't be so critical to meet some new RHS code in
> this switch.  We may always say that we cannot find proper bounds and
> use default ones.  I replaced gcc_uneachable with a warning about
> lost bounds and added a comment into tree.def.  Would it be enough?
It'd be better than hitting the gcc_unreachable :-)  It's not perfect, 
but probably good enough.

Jeff