summaryrefslogtreecommitdiffstats
path: root/lib/libcxxrt
diff options
context:
space:
mode:
authorjhb <jhb@FreeBSD.org>2015-04-09 19:36:06 +0000
committerjhb <jhb@FreeBSD.org>2015-04-09 19:36:06 +0000
commit107a51b87f516e0a578d0a40ce21399c4d612e9d (patch)
tree8c06a1ac00f83852efeab556cd073920fd1a6687 /lib/libcxxrt
parentde91cfb1641ad37c56d8cc6360dd818198dd58e6 (diff)
downloadFreeBSD-src-107a51b87f516e0a578d0a40ce21399c4d612e9d.zip
FreeBSD-src-107a51b87f516e0a578d0a40ce21399c4d612e9d.tar.gz
MFC 279949:
The System V ABI for amd64 allows functions to use space in a 128 byte redzone below the stack pointer for scratch space and requires interrupt and signal frames to avoid overwriting it. However, EFI uses the Windows ABI which does not support this. As a result, interrupt handlers in EFI push their interrupt frames directly on top of the stack pointer. If the compiler used the red zone in a function in the EFI loader, then a device interrupt that occurred while that function was running could trash its local variables. In practice this happens fairly reliable when using gzipfs as an interrupt during decompression can trash the local variables in the inflate_table() function resulting in corrupted output or hangs. Fix this by disabling the redzone for amd64 EFI binaries. This requires building not only the loader but any libraries used by the loader without redzone support. Thanks to Jilles for pointing me at the redzone once I found the stack corruption.
Diffstat (limited to 'lib/libcxxrt')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud