Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2015-03-24 17:06 GMT+03:00 Jakub Jelinek <jakub@redhat.com>:
> On Tue, Mar 24, 2015 at 12:22:27PM +0300, Ilya Enkovich wrote:
>> 2015-03-24 11:33 GMT+03:00 Jakub Jelinek <jakub@redhat.com>:
>> > On Thu, Mar 19, 2015 at 11:29:44AM +0300, Ilya Enkovich wrote:
>> >> +  /* We might propagate instrumented function pointer into
>> >> +     not instrumented function and vice versa.  In such a
>> >> +     case we need to either fix function declaration or
>> >> +     remove bounds from call statement.  */
>> >> +  if (callee)
>> >> +    skip_bounds = chkp_redirect_edge (e);
>> >
>> > I just want to say that I'm not really excited about all this compile time
>> > cost that is added everywhere unconditionally for chkp.
>> > I think much better would be to guard most of it with proper option check
>> > first and only do the more expensive part if the option has been used.
>>
>> Agree, overhead for not instrumented code should be minimized.
>> Unfortunately there is no option check I can use to guard chkp codes
>> due to LTO. Currently it is allowed to pass -fcheck-pointer-bounds for
>> IL generation and don't pass it for final code generation. I suppose I
>> may set this (or some new) flag if see instrumented node when read
>> cgraph and then use it to guard chkp related codes. Would it be
>> acceptable?
>
> The question is what you want to do in the LTO case for the different cases,
> in particular a TU compiled with -fcheck-pointer-bounds and LTO link without
> that, or TU compiled without -fcheck-pointer-bounds and LTO link with it.
> It could be handled as LTO incompatible option, where lto1 would error out
> if you try to mix -fcheck-pointer-bounds with -fno-check-pointer-bounds
> code, or e.g. similar to var-tracking, you could consider adjusting the IL
> upon LTO reading if if some TU has been built with -fcheck-pointer-bounds
> and the LTO link is -fno-check-pointer-bounds.  Dunno what will happen
> with -fno-check-pointer-bounds TUs LTO linked with -fcheck-pointer-bounds.
> Or another possibility is to or in -fcheck-pointer-bounds from all TUs.

Mixing instrumented and not instrumented TUs is allowed. All
instrumentation passes happen before LTO link. The only code
generation problem if instrumented code is linked with no
-fcheck-pointer-bounds is disabled chkp_finish_file call which
generates static constructors. I think I just should set
flag_check_pointer_bounds if see any instrumented symbol on LTO read.
It would cause chkp_finish_file call when required and would be
available as guard for chkp related codes.

>
>> Maybe replace attribute usage with a new flag in tree_decl_with_vis structure?
>
> Depends, might be better to stick it into cgraph_node instead, depends on
> whether you are querying it already early in the FEs or just during GIMPLE
> when the cgraph node should be created too.

Flag in cgraph_node should work. I'll have a look.

Thanks,
Ilya

>
>         Jakub