This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 25 Mar 2015 09:16:20 +0100
- Subject: Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers
- Authentication-results: sourceware.org; auth=none
- References: <20150312100931 dot GK27860 at msticlxl57 dot ims dot intel dot com> <20150319082944 dot GC64546 at msticlxl57 dot ims dot intel dot com> <20150324083325 dot GC1746 at tucnak dot redhat dot com> <CAMbmDYbs2GEy3=gQ1+3NDZuqATeiRZbhfucsx3AWP8Zmq2zogA at mail dot gmail dot com> <20150324140619 dot GE1746 at tucnak dot redhat dot com> <CAMbmDYZ3XhwhdDKPSyPHeQ79EjQueQ-WTggqsXq3Ryz+Ed4+eA at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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