This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]