On Wed, Mar 25, 2015 at 11:05:17AM +0300, Ilya Enkovich wrote:
> > 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.
Thus perhaps oring the flag_check_pointer_bounds option from all the TUs is
the desirable behavior for LTO?
I think Richard or Honza would know where would be the best spot to do that.
Jakub
