On Fri, Jul 17, 2020 at 12:03 AM Richard Biener <rguent...@suse.de> wrote: > > On Wed, 15 Jul 2020, H.J. Lu wrote: > > > On Wed, Jul 15, 2020 at 8:20 AM Richard Biener <rguent...@suse.de> wrote: > > > > > > On Wed, 15 Jul 2020, H.J. Lu wrote: > > > > > > > With --enable-cet, require CET support only for the final GCC build. > > > > Don't enable CET without CET support in stage1 nor for build support. > > > > > > I wonder if we want to do sth less fragile than testing > > > for ../stage_current - for example the toplevel make could > > > export sth special through POSTSTAGE1_FLAGS_TO_PASS? > > > > That would be nice. > > > > > But note one of the issues is that when not cross-compiling we're > > > using a single libiberty for target and host objects (likewise > > > > It shouldn't be a problem. > > > > > for libstdc++ I guess). When cross-compiling say powerpc -> x86_64 > > > we should already build stage1 libiberty used for target objects > > > by the stage1 compiler and thus CET enabled. > > > > > > Note that for PR96202 it's host objects (gen*) that we get complaints > > > for - the host objects should never get CET enabled. > > > > We must enable CET in lto-plugin on CET enabled hosts even if > > CET isn't enabled in GCC run-time. Otherwise, ld can't dlopen > > lto-plugin. > > But then don't we also need to enable CET for _all_ host objects?
No. We only need those which may be dlopened on CET enabled hosts. > Note libiberty for the build also seems instrumented leading to > LTO link fail when building gen* - so you probably mean that > lto-plugin for the _build_ needs to be CET enabled? But then Yes, for CET enabled build and CET enabled host. > gen* would need such CET enablement, too? Will gen* be dlopened? > In any case we might want to try to disentangle CET enablement > for the build/host from that of the target? > > > > That said, giving configury an idea whether it configures for > > > the host, the target or the build would be required here - Joseph, > > > is there an existing mechanism for example libiberty can use > > > here? > > > -- H.J.
