diff options
author | Sudakshina Das <sudi.das@arm.com> | 2020-03-17 15:44:18 +0000 |
---|---|---|
committer | Szabolcs Nagy <szabolcs.nagy@arm.com> | 2020-07-08 15:02:37 +0100 |
commit | 91181954f94917b1e1ae591c60cbadf0321d35af (patch) | |
tree | 8496a8e4cb39e210eea7f8ed9e5bb208ff8556bc /setjmp | |
parent | 2a4c2dde4918c2c4e443e8328eab97db2c26e327 (diff) | |
download | glibc-91181954f94917b1e1ae591c60cbadf0321d35af.tar.gz glibc-91181954f94917b1e1ae591c60cbadf0321d35af.tar.xz glibc-91181954f94917b1e1ae591c60cbadf0321d35af.zip |
aarch64: Add BTI support to assembly files
To enable building glibc with branch protection, assembly code needs BTI landing pads and ELF object file markings in the form of a GNU property note. The landing pads are unconditionally added to all functions that may be indirectly called. When the code segment is not mapped with PROT_BTI these instructions are nops. They are kept in the code when BTI is not supported so that the layout of performance critical code is unchanged across configurations. The GNU property notes are only added when there is support for BTI in the toolchain, because old binutils does not handle the notes right. (Does not know how to merge them nor to put them in PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions of binutils emit warnings about the unknown GNU property. In such cases the produced libc binaries would not have valid ELF marking so BTI would not be enabled.) Note: functions using ENTRY or ENTRY_ALIGN now start with an additional BTI c, so alignment of the following code changes, but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the existing code layout. Some string functions may need to be tuned for optimal performance after this commit. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Diffstat (limited to 'setjmp')
0 files changed, 0 insertions, 0 deletions