This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 21 Nov 2017 12:33:02 +0000
- Subject: [Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs
- Auto-submitted: auto-generated
- References: <bug-83087-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to igor.v.tsimbalist from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > My understanding has been that the CET stuff is essentially ABI incompatible
> > (CET enabled libraries/binaries vs. non-CET enabled ones) on CET HW, so it
> > should be better treated like a multilib.
> > So, unless everything on the system is CET enabled, putting the CET support
> > in is just waste of I-cache.
>
> It's completely ABI compatible. ABI has not changed. You can mix object
> files. But it's true that an app is CET enabled if all object files and
> libraries linked in the app are CET enabled.
So there is some assembler/linker and dynamic linker magic that disables CET
for the process if not all libraries have the CET support? If yes, what
happens if a process where the binary and all libraries it links directly
against are CET enabled and you dlopen a library that is not?