This is the mail archive of the 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: [RFC] Using function clones for Pointer Bounds Checker

On 01/14/14 02:15, Ilya Enkovich wrote:

I've been working for some time on the prototype of the Pointer Bounds
Checker which uses function clones for instrumentation
( After
several experiments with this approach I want to share my results and
ask for some feedback to make a decision about the future steps.
Sorry for the delayed reply, when you sent this message I was ignoring anything that wasn't an open issue for GCC 4.9 -- it all gets thrown into a massive queue of things to come back to once stage1 reopens.

So I really like the idea of trying to use function clones to simplify some of the details of implementing MPX support.

Clones approach does not use special built-in function calls to
associate bounds with call arguments and input parameters. Each
function which should be instrumented gets an additional version and
only this special version will be instrumented.
I like this.

This new version gets
additional bound arguments to express input bounds. When function call
is instrumented, it is redirected to instrumented version and all
bounds are passed as explicit call arguments. Thus we have explicit
pointer bounds flow similar to regular function parameters. It should
allow to avoid changes in optimization, avoid miss-optimizations,
allow existing IPA optimizations to work with bound args (e.g.
propagate constant bounds value and remove checks in called function).
So from a linking standpoint, presumably you have to mangle the instrumented caller/callee in some manner. Right? Or are you dynamically dispatching somehow?

1. Nodes reachability. Instrumented version is actually always
reachable when original function is reachable because it is always
emitted instead of the original. Thus I had to fix reachability
analysis to achieve it. Another similar problem is check whether node
can be removed after inline when inlining instrumented function. Not
hard to fix but probably other similar problems exist.
Jan is going to be the best person to discuss these issues with you. He's the architect behind most of the IPA bits we've got right now.

In general I feel that having special function version for
instrumentation has a better potential, should lead to less intrusive
changes in the compiler and better code quality.
Agreed.  It seems *much* cleaner.


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