summaryrefslogtreecommitdiff
path: root/src/lib/libc/stdlib/exit.c
diff options
context:
space:
mode:
authorjsing <>2022-07-30 13:51:31 +0000
committerjsing <>2022-07-30 13:51:31 +0000
commitb501550b32ce2e071cf3b7543b3fbea7ec536a11 (patch)
tree3ba97f39872a992e0d8d5296e1139550cece1379 /src/lib/libc/stdlib/exit.c
parent1cf7b34b847eab95bca1e8ca960305109169bf2d (diff)
downloadopenbsd-b501550b32ce2e071cf3b7543b3fbea7ec536a11.tar.gz
openbsd-b501550b32ce2e071cf3b7543b3fbea7ec536a11.tar.bz2
openbsd-b501550b32ce2e071cf3b7543b3fbea7ec536a11.zip
Add stack frames to AES-NI x86_64 assembly.
The current AES-NI x86_64 assembly does some strange, although valid things, such as making internal function calls without creating stack frames. In this case, the return address lands in the red zone (which it allows for when making use of the stack) and everything works as expected. However, this trips a false positive in valgrind, which seems to think that any data saved on the stack prior to the internal function call is now "undefined" once the function returns. Avoid this by actually using stack frames - this brings in most of 6a40ebe86b4 from OpenSSL, omitting the unnecessary explicit stack alignment (which was apparently added so this code could be used in the Linux kernel with an incorrectly aligned stack). Valgrind issue reported by Steffen Jaeckel (@sjaeckel), found via libstrophe unit tests. ok tb@
Diffstat (limited to 'src/lib/libc/stdlib/exit.c')
0 files changed, 0 insertions, 0 deletions